Re: [riot-devel] Odd problems with xtimer

[Michael Andersen]

Hi

I am using other IPC messages, yes. There is a thread waiting with
xtimer_msg_receive_timeout that gets messages either from xtimer_set_msg or
from the network stack on packet reception.

Incidentally, if I decrease the load on the MCU by increasing the sensor
sampling interval, the problem seems to go away (or at least it has not
shown again in the past day).

I inserted a trap in the timer code that will stop everything and let me
debug if a timer is found in the linked list with the same address as the
timer to be inserted, I'll let you know again with more info when I
reproduce it.

Thanks
Michael



On Thu, Feb 11, 2016 at 2:05 AM, Joakim Nohlgård 
wrote:

> Also, you can use the .map file to find out if there are any buffers
> or other things nearby which may have overflowed and messed up your
> state.
>
> Are you using any IPC messages other than the xtimer functions?
> (I wonder if there might be a race between the timer ISR callbacks and
> the message reception in xtimer)
>
> Regards, Joakim
>
> On Wed, Feb 10, 2016 at 11:21 PM, Martine Lenders
>  wrote:
> > Hi,
> > normally you can guess where the timer came from by looking at the
> address
> > (or the debugger straight tells you). Is this somehow possible for your
> case
> > (i.e. 0x200010a4)? That might be helpful for the timer people.
> >
> > Regards,
> > Martine
> >
> > 2016-02-10 23:08 GMT+01:00 Michael Andersen :
> >>
> >> Hi
> >>
> >> Thanks for the reply. I am on a platform essentially equal to a
> >> samr21xpro.
> >>
> >> The short answers:
> >>  - samr21xpro
> >> - only one declared xtimer_t object that is used more than once. I use
> it
> >> with xtimer_set_msg for a thread to send itself a message. Both the
> timer
> >> and the msg object are statically allocated. On the other hand, I have
> RPL
> >> and all sorts of network things going and I have no doubt there are a
> ton of
> >> timers involved. In terms of ephemeral timers, I call xtimer_usleep a
> LOT
> >> with intervals of between 1ms and 100ms from multiple threads. I also
> send
> >> packets every 200ms or so and receive them every 500ms or so.
> >>  -The interrupt load might be pretty steep if the radio is interrupting
> on
> >> every packet (promiscuous mode). I don't think it is. Otherwise I would
> >> imagine that other than the timers it is less than ten per second.
> >>
> >> As for memory corruption, that may well be the case. I will double check
> >> my code. I thought it was somewhat unusual that multiple boards would
> all
> >> get a timer pointing to itself, but I suppose not all corruption is
> >> non-deterministic and they all run identical firmware, so it might be
> >> corruption.
> >>
> >> One question, in the network stacks, are there ever two threads possibly
> >> using the same timer object? I ask because the timer_remove and the
> insert
> >> are in two different critical sections, and if there are concurrent
> calls
> >> with the same timer object then it might be possible to interrupt
> between
> >> the critical sections and insert a timer that is already in the list.
> What
> >> would then happen is that this loop would end with list_head equal to
> the
> >> timer (assuming no other timer has the same time), and then the next two
> >> lines would basically link the timer to itself.
> >>
> >> I could be wrong though, that is just a guess.
> >>
> >>
> >> On Wed, Feb 10, 2016 at 2:45 AM, Kaspar Schleiser 
> >> wrote:
> >>>
> >>> Hey Michael,
> >>>
> >>> On 02/10/2016 07:57 AM, Michael Andersen wrote:
> >>> > it seems that one of the nodes in the list points to itself, hence
> the
> >>> > endless loop.
> >>> >
> >>> > My first question is: when is this possible? It seems at first glance
> >>> > that all code paths that lead here call remove_timer to prevent this
> >>> > sort of problem.
> >>> It should not be possible (tm).
> >>>
> >>> I took another look at the code, it seems to me that timer->next gets
> >>> overwritten whenever a timer is set, so there can't be some outdated
> >>> value.
> >>>
> >>> It might be that the list logic has a bug somewhere, but I remember
> >>> testing them quite rigourously.
> >>>
> >>> > I don't access a the same timer object from two
> >>> > different threads. My code using xtimer functions is not reentered.
> >>> >
> >>> > I don't use that many timer operations in my application code, but I
> do
> >>> > assume that the following functions don't require any freeing or
> >>> > removing afterwards, am I wrong?
> >>> Completely right.
> >>>
> >>> Could you tell us more on how you are using timers?
> >>>
> >>> Interesting would be things like
> >>>
> >>> - what platform are you on
> >>> - how many timers are simultaneously active
> >>> - how are the intervals
> >>> - how is the interrupt load
> >>>
> >>> ... that might help corner the issue.
> >>>
> >>> You should consider xtimer just showing a problem which might be caused
> >>> by memory corruption.
> >>>
> >>> Kaspar
> >>> ___
> 

Re: [riot-devel] IPv6 NDP router advertisement from global address

[Martine Lenders]

Hi Michael,
would it be possible for you to open an issue for that on GitHub
(preferably with a sniffer dump)? Currently I'm short of time to look into
it, but later on I could / someone else could bite there teeth into it.

Cheers,
Martine

2016-02-12 5:53 GMT+01:00 Michael Andersen :

> Hi
>
> My nodes are getting "invalid" router advertisements a whole lot, and
> falling out here
> 
>  which
> is causing a severe decrease in mesh reliability.
>
> Specifically, it is the first check: the IPv6 source address is not link
> local. (And I have verified that with a sniffer, the packets contain a full
> 128-bit inlined global address). I don't know the standards well enough to
> know who is at fault here, but I reckon either the sender or the receiver
> must be wrong :-)
>
> Does anyone know if this requirement is true? That router advertisements
> in response to router solicitations must contain link-local source
> addresses? Incidentally, the node responding is one link away, so it could
> have used a link-local address, it just chose not to.
>
> Thanks again for your help
> Michael
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Problems during porting RIOT-OS

[Hauke Petersen]

Hi Bernhard,

I can't really tell what's causing this behavior, seems to me though 
that there is something wrong in the UART configuration. But it's hard 
to tell without seeing your code. Which board are you using? Some STM 
nucleo one? The boards are notorious for weird behavior of their 
UART-USB converters under Linux...


To your second question: the `lpc_arch.c` is exactly the place to 
implement switchting to low-power modes.


Cheers,
Hauke


On 11.02.2016 23:24, Bernhard Nägele wrote:
Hello, I am trying to port RIOT-OS to the STM32L053 MCU and I get 
stuck at the moment.
The base system seems to work - every time I stop the system with the 
emulation probe I
can see that the system is in the idle-thread and I can single-step 
until I reach the next idle-thread.
The misterious thing is that the main task is never executed. No 
"Hello World" on the serial
interface. One character is seen by a terminal software after each 
restart, but not more.
Have you any idea what could going wrong at that step. The UART is 
set-up correctly, because

I got the dummy handler message before I worked at the vectors.c file.

Question 2: I want to use the Low Power Timer of the STM32L053 during 
the idle thread (stop-mode).
Can you give me a hint, where to place the change-over from the normal 
clock to the LPTimer?

lpm_arch.c ?

Best regards,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Unable to build in native

[Jose Alamos]

Hi!

It seems to be a problem with libgcc. You could try this:
http://askubuntu.com/questions/346377/cannot-find-lgcc-s

Or this:
http://serverfault.com/questions/266138/cannot-find-lgcc-s-from-gcc-3-4-on-unbuntu-11-04

Best regards.

2016-02-12 9:00 GMT+01:00 :

> Send devel mailing list submissions to
> devel@riot-os.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.riot-os.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
> devel-requ...@riot-os.org
>
> You can reach the person managing the list at
> devel-ow...@riot-os.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of devel digest..."
>
>
> Today's Topics:
>
>1. accidentally commited to master (Landsmann, Martin)
>2. Re: accidentally commited to master (Joakim Nohlgård)
>3. Re: accidentally commited to master (Landsmann, Martin)
>4. no main-thread while making a port to a new MCU (Bernhard Nägele)
>5. Problems during porting RIOT-OS (Bernhard Nägele)
>6. IPv6 NDP router advertisement from global address
>   (Michael Andersen)
>7. Unable to build in native (tobaccopipeyoyo .)
>
>
> --
>
> Message: 1
> Date: Thu, 11 Feb 2016 12:11:59 +
> From: "Landsmann, Martin" 
> To: RIOT OS kernel developers ‎[devel@riot-os.org]‎
> 
> Subject: [riot-devel] accidentally commited to master
> Message-ID:
> <
> 2d3546f9ea22ab48a00276a6f528bd0140efb...@mb04.mailcluster.haw-hamburg.de>
>
> Content-Type: text/plain; charset="cp1256"
>
> Hi guys,
>
> I accidentally commited directly to master ): [1]
> Is there a way to revert it?
>
> Best Regards,
> Martin
>
> [1]
> https://github.com/RIOT-OS/RIOT/commit/30ab6883331e29ce8453ebc1057f939575e6
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.riot-os.org/pipermail/devel/attachments/20160211/e2689b0e/attachment-0001.html
> >
>
> --
>
> Message: 2
> Date: Thu, 11 Feb 2016 13:17:35 +0100
> From: Joakim Nohlgård 
> To: RIOT OS kernel developers 
> Subject: Re: [riot-devel] accidentally commited to master
> Message-ID:
>  ch4rpvsdvjpwnqbg5v-tkj1pxmcri0k5...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I think it is better to make a revert commit and push that as well, that
> avoids the problem of rewritten history.
>
> git revert 30ab6883331e29ce8453ebc1057f939575e6
> git push
>
> To prevent mistakes like this in the future, change the upstream repo URL
> to use the https:// or git:// links instead of ssh://
>
> Best regards,
> Joakim
>
> On Thu, Feb 11, 2016 at 1:11 PM, Landsmann, Martin <
> martin.landsm...@haw-hamburg.de> wrote:
>
> > Hi guys,
> >
> > I accidentally commited directly to master ): [1]
> > Is there a way to revert it?
> >
> > Best Regards,
> > Martin
> >
> > [1]
> >
> https://github.com/RIOT-OS/RIOT/commit/30ab6883331e29ce8453ebc1057f939575e6
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.riot-os.org/pipermail/devel/attachments/20160211/75812d56/attachment-0001.html
> >
>
> --
>
> Message: 3
> Date: Thu, 11 Feb 2016 12:25:53 +
> From: "Landsmann, Martin" 
> To: RIOT OS kernel developers 
> Subject: Re: [riot-devel] accidentally commited to master
> Message-ID:
> <
> 2d3546f9ea22ab48a00276a6f528bd0140efb...@mb04.mailcluster.haw-hamburg.de>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Did revert, again sorry for that ):
> and @gebart thx for the hint
>
> Best regards,
> Martin
>
> 
> Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård [
> joakim.nohlg...@eistec.se]
> Gesendet: Donnerstag, 11. Februar 2016 13:17
> An: RIOT OS kernel developers
> Betreff: Re: [riot-devel] accidentally commited to master
>
> I think it is better to make a revert commit and push that as well, that
> avoids the problem of rewritten history.
>
> git revert 30ab6883331e29ce8453ebc1057f939575e6
> git push
>
> To prevent mistakes like this in the future, change the upstream repo URL
> to use the https:// or git:// links instead of ssh://
>
> Best regards,
> Joakim
>
> On Thu, Feb 11, 2016 at 1:11 PM, Landsmann, Martin <
> martin.landsm...@haw-hamburg.de>
> wrote:
> Hi guys,
>
> I accidentally commited directly to master ): [1]
> Is there a way to revert it?
>
> Best Regards,
> Martin
>
> [1]
> https://github.com/RIOT-OS/RIOT/commit/30ab6883331e29ce8453ebc1057f939575e6
>
> ___
> devel mailing list
> devel@riot-os.org
> https://

Re: [riot-devel] Unable to build in native

[Cenk Gündogan]

Hey tbyy,

Did you install the gcc-multilib package on ubuntu?

Best,
Cenk

On 12.02.2016 09:00, tobaccopipeyoyo . wrote:

Hi everyone,
Sorry to disturb y'all.
This is my second post here, still not able to build the native code

This is the output that am getting.
"make" -C /home/riot/RIOT/sys/shell
"make" -C /home/riot/RIOT/sys/shell/commands
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for
-lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
make: *** [all] Error 1


It would be great if you could provide some insight.

Thanks,
tbyy

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.3-8ubuntu2~14.04'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04)
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Unable to build in native

[Joakim Nohlgård]

See if you have g++multilib installed (32 bit versions of GCC libraries for
64 bit systems), otherwise install it:

sudo apt-get install g++-multilib

Best regards,
Joakim

On Fri, Feb 12, 2016 at 9:00 AM, tobaccopipeyoyo . <
tobaccopipey...@gmail.com> wrote:

> Hi everyone,
> Sorry to disturb y'all.
> This is my second post here, still not able to build the native code
>
> This is the output that am getting.
> "make" -C /home/riot/RIOT/sys/shell
> "make" -C /home/riot/RIOT/sys/shell/commands
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
> /usr/bin/ld: cannot find -lgcc
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for
> -lgcc_s
> /usr/bin/ld: cannot find -lgcc_s
> collect2: error: ld returned 1 exit status
> make: *** [all] Error 1
>
>
> It would be great if you could provide some insight.
>
> Thanks,
> tbyy
>
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.9.3-8ubuntu2~14.04'
> --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.9 --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --enable-gnu-unique-object --disable-vtable-verify --enable-plugin
> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
> --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
> --with-arch-directory=amd64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04)
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Unable to build in native

[tobaccopipeyoyo .]

Hi everyone,
Sorry to disturb y'all.
This is my second post here, still not able to build the native code

This is the output that am getting.
"make" -C /home/riot/RIOT/sys/shell
"make" -C /home/riot/RIOT/sys/shell/commands
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for
-lgcc_s
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
make: *** [all] Error 1


It would be great if you could provide some insight.

Thanks,
tbyy

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.3-8ubuntu2~14.04'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.3 (Ubuntu 4.9.3-8ubuntu2~14.04)
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel