Problem with RPL-UDP example for SAMR21

Hi,

I am facing problems with rpl_udp example on samr21 board. Each time I try to debug the code on the board, it goes to « isr_hard_fault ». Is there somebody who managed to make it run one samr21 ?

Cheers,

Maxence

Hi Maxence!

I am facing problems with rpl_udp example on samr21 board. Each time I try to debug the code on the board, it goes to < isr_hard_fault >. Is there somebody who managed to make it run one samr21 ?

Not yet, but I could try. On which branch are you trying?

Cheers, Oleg

P.S. One of the most common problems if running into an hard fault, is that one of the stack sizes is too small. You could try to add a `thread_print_all()` to the isr_hard_fault() handler in https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/startup.c#L104.

I downloaded it on the Riot master branch today

-----Message d'origine-----

Hi!

I downloaded it on the Riot master branch today

But since https://github.com/RIOT-OS/RIOT/pull/1997 isn't merged, how do you access the radio?

Cheers, Oleg

Yes right, I work on this branch : https://github.com/Troels51/RIOT/tree/samr21-transceiver-port

-----Message d'origine-----

Hi!

Yes right, I work on this branch : https://github.com/Troels51/RIOT/tree/samr21-transceiver-port

Ok, I'll try tomorrow if I can find one to borrow me another board.

Cheers, Oleg

Hi Oleg,

Did you find something about my problem ?

Cheers, Maxence

-----Message d'origine-----

Hi Maxence!

Did you find something about my problem ?

Sorry for the lack of responsiveness. I had some weird problems with the board last Friday (couldn't get any output using the rpl_udp example, while other examples work fine). Will investigate further and let you know as soon as I figure something out.

Cheers, Oleg

Hi Oleg !

Thank you for your help !

Maxence

-----Message d'origine-----

Hello Oleg, What is the RAM size required for running a RIOT with full 6LoWPAN and RPL ?

-Akshay

Hi Akshay,

that depends on the board.

Please checkout this application https://github.com/RIOT-OS/applications/tree/master/sixlowapp and compile (make clean all) it for your board.

Note: This only works if there is a transceiver configured. For the samr21-xpro that means you have to merge the branch of the pull request which adds transceiver support first.

Afterwards, add the values printed for bss and data to get the static RAM usage. Similarly, add bss and text to calculate ROM usage.

Cheers, Ludwig

Hi,

sorry, I misread the "and RPL" to mean "without RPL" because I had that question the other day. To get sizes with RPL, just use the examples/rpl_udp instead of sixlowapp from applications.

BTW: You might also want to look at this while you're at it. https://github.com/RIOT-OS/RIOT/pull/2155

It should reduce the RAM need quite a bit.

Cheers, Luwig

Thanks Ludwig, We are using the SAMR21 and the bss is nearly 32k which is as good as the RAM size (for the rpl_udp) ! No wonder it crashes.

-Akshay

Hello RIOTers, I wanted to know if the 32KB of SRAM on the SAMR21 will be sufficient to run the RPL ? Is there some footprint statistic that one can consider when planning a probable system architecture.

-Akshay

Hi,

Maybe I misunderstand what you mean by "probably system architecture".. please elaborate if none of this makes any sense.

Regarding memory requirements, this depends on your application entirely. How many threads does it need, how much memory do they each need.. You could sketch the application and use the ps command to see how much memory is actually being used within each thread. Depending on which modules you want use, they might introduce more threads. So make sure to add everything you are going to use to the application Makefile.

As for the need of dynamic heap memory (via malloc), maybe Martine and Cenk could shed some light on how much is needed?

Finally, there is some room for optimization in the network stack. In case your applications needs are too large, there should be some low hanging fruit. Also, the stack is under heavy reconstruction right now, so it's kind of hard to predict for me how the situation will look in a month.. Martine and Cenk, maybe you want to do some wild guessing? :wink:

By the way: If you want to start optimizing but don't know where to start, I wrote https://github.com/LudwigOrtmann/otm to quickly assess static memory consumption in a graphical manner.

For rpl (1997 rebased on master) on the sam it looks like this (BSS+data): http://ludwig.spline.inf.fu-berlin.de/samr21-xpro%20rpl_udp%20RAM.jpeg (368 + 32144 = 32144/32768 RAM)

After merging 2155, it changes to: http://ludwig.spline.inf.fu-berlin.de/samr21-xpro%20rpl_udp%20RAM%202155.jpeg (368 + 29016 = 29384/32768 RAM)

Cheers, Ludwig

PS: The command to create the graphics was: `otm.py -t dDbB bin/samr21-xpro/rpl_udp.elf -m 60` `-t dDbB` selects un/Initialized data and BSS symbols, so only RAM is shown. `-m 60` filters out symbols which are smaller than 60 bytes to unclutter the plot. Note that the box sizes are proportional to the sum of all symbols shown, therefore the image itself does not shrink. The otm branch is "section_hue_2".

Hi Akshay!

           I wanted to know if the 32KB of SRAM on the SAMR21 will be sufficient to run the RPL ? Is there some footprint statistic that one can consider when planning a probable system architecture.

It is definitely our goal to archive support for a full featured network stack with RPL, 6LoWPAN (w/ support for full IPv6 MTU), and UDP within 32kB RAM on a 32-bit platform (such as the SAMR21).

Currently, however, there are some issues to consider: 1.) We're completely re-implementing the whole network stack. The new version     will be less memory hungry. In the current (aka legacy) network stack     every layer keeps its own buffer, while the new version will make use of a     global, shared buffer. I think the work on the new network stack will be     completed in early Q1 2015. 2.) The current default for RPL is the storing mode (MOP 2) with a maximum     routing table size of 128 entries. Since dynamic memory allocation for     most IoT applications is a bad choice and each entry consists of two full     IPv6 addresses, a static array is allocated for the routing table. Hence,     alone the routing table will consume more than 4k of RAM, if you build a     RPL application in the default configuration. The size of the routing     table can be configured at compile time by supplying     RPL_MAX_ROUTING_ENTRIES=X. The MOP can be set in     sys/net/include/rpl/rpl_config.h

Hope that helps.

Cheers, Oleg

Thanks Ludwig and Oleg. This was what I was looking for. I believe optimization will have to wait till the new release which should be fine for me.

Thanks and Regards, Akshay