Cannot setup 6lowPAN testbed for cc2538dk

[claudyus]

Hi all,
I'm trying to setup a 6LowPAN network using the cc2538dk following the guide in [1]. What I experience is a problematic reboot cycle during tunslip6 initialization.

In the snippet below you can see that the chip is rebooting after Setting prefix aaaa:::

$ sudo ./tunslip6 -s /dev/ttyUSB1 aaaa::1/64 -v
********SLIP started on ``/dev/ttyUSB1''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add aaaa::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.1.1  P-t-P:127.0.1.1  Mask:255.255.255.255
          inet6 addr: fe80::1/64 Scope:Link
          inet6 addr: aaaa::1/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

*** Address:aaaa::1 => aaaa:0000:0000:0000
Got configuration message of type P
Setting prefix aaaa::
Contiki-2.6-1794-g6fb7dd2
TI SmartRF06 + cc2538EM
 Net: sicslowpan
 MAC: CSMA
 RDC: ContikiMAC
Rime configured with address 00:12:4b:00:03:a6:51:5b
*** Address:aaaa::1 => aaaa:0000:0000:0000
Got configuration message of type P
Setting prefix aaaa::
Contiki-2.6-1794-g6fb7dd2
TI SmartRF06 + cc2538EM
 Net: sicslowpan
 MAC: CSMA
 RDC: ContikiMAC
Rime configured with address 00:12:4b:00:03:a6:51:5b
*** Address:aaaa::1 => aaaa:0000:0000:0000
Got configuration message of type P
Setting prefix aaaa::
^Csignal 2

How I can debug this problem? Any hit about a specific settings that can help?

Did you can suggest a specific version of contiki that is know to work?
I'm using rev 6fb7dd2, actual branch master at the moment.

Thanks
Claudio

1. https://github.com/contiki-os/contiki/blob/master/platform/cc2538dk/README.md#build-a-6lowpan-testbed

[claudyus]

I remove all webserver stuff from the code and now it is correctly work, the firmware stop rebooting and tunslip6 is showing me the correct ipv6 address.

Any idea about the reason for this behavior?

[darkopetrovic]

I've used an older revision (4c5fa6f / 13 Jun 2014) with the CC2538dk and I've not encountered this problem with tunslip6. If your system is continuously rebooting this is surely related to the watchdog. If contiki reboots like this that means it has crashed somewhere. It is a good thing to try an older revision you'll be fixed.

[claudyus]

Hello @darkopetrovic ,
I have tested the older revision that you suggest to me and I can confirm that in 4c5fa6f including the webserver code doesn't triggers the bug.

I made a bisect using the test script in [1] and a modified version of SmartRF06EB [2] for autotest purpose.

Here all the detail about the successful bisect, I hope that some one with deep knowledge of contiki internals could find the root of this issues.

# bad: [a50bc08adc776120acc76140093760a71c32c320] Merge pull request #841 from gebart/build-git-tag-io-reduce
# good: [4c5fa6ff5dbb93ca82d2dda556d3cad0367f981d] Merge pull request #713 from adamdunkels/pr/drop-iris
git bisect start 'upstream/master' '4c5fa6ff5dbb93ca82d2dda556d3cad0367f981d'
# bad: [e5653ac1505623c8fff004c43f7e1eea241f1f16] [cooja] Memory: Added add/removeMemoryMonitor functions
git bisect bad e5653ac1505623c8fff004c43f7e1eea241f1f16
# bad: [17f54ad562f23d5a2f6387adb0bdb1f12ba7be66] Merge pull request #759 from jimparis/aducrf101-fix-stack
git bisect bad 17f54ad562f23d5a2f6387adb0bdb1f12ba7be66
# bad: [d7cf3b1f74159dead531d9a0da6fcd02ad6cdb5d] Merge pull request #753 from kartben/patch-1
git bisect bad d7cf3b1f74159dead531d9a0da6fcd02ad6cdb5d
# bad: [ed87b928c51b25a9865952bc28b2664ecb6a77ff] Merge pull request #734 from hexluthor/rl78-linkaddr
git bisect bad ed87b928c51b25a9865952bc28b2664ecb6a77ff
# bad: [ad4c1b92189d04b4f62a0797c5612121c3eb8d38] Merge pull request #729 from g-oikonomou/fix-nd6-sdcc
git bisect bad ad4c1b92189d04b4f62a0797c5612121c3eb8d38
# bad: [a9e7bea675c4f8b868674c701ad8191922459ed7] Make DODAG ID selection RFC 6550-compliant
git bisect bad a9e7bea675c4f8b868674c701ad8191922459ed7
# good: [32bc98b0dad10c70515f08ac1245247c166d235a] Fix code style in rpl_set_root prototype
git bisect good 32bc98b0dad10c70515f08ac1245247c166d235a
# first bad commit: [a9e7bea675c4f8b868674c701ad8191922459ed7] Make DODAG ID selection RFC 6550-compliant

Reverting the a9e7bea resolve the problem, I hope that @g-oikonomou can help us to understand the bug.

1. https://gist.github.com/claudyus/43e2f9000a869b9b8d6c
2. https://www.dropbox.com/s/ijes7fzpcho66oq/2014-11-03%2014.55.13.jpg?dl=0

[g-oikonomou]

I've meant to try this one out but I've not found a chance (don't hold your breath :()

I'm a little confused by your post though. You say that a9e7bea works, but in the bisect it's marked as bad? This commit did in fact touch border-router.c, but I can't see how the commit may have broken it ina a way that disabling the webserver would make it work.

With the latest version and zero modifications, does this report reasonable values?

$ arm-none-eabi-size border-router.elf

I'd also try with a different version of the toolchain and I'd play around with the SMALL make variable

[claudyus]

Hi @g-oikonomou,

I didn't know which one could be consider a reasonable values, anyway here the detail with zero code modification:

$ git log -1 --oneline 
a50bc08 Merge pull request #841 from gebart/build-git-tag-io-reduce
$ arm-none-eabi-size border-router.elf
   text    data     bss     dec     hex filename
  46796     489   10160   57445    e065 border-router.elf

The problem is still present and reproducible with the version above.

Below I revert the commit and retest the code with success:

$ git revert a9e7bea675c4f8b868674c701ad8191922459ed7
[detached HEAD a2983a3] Revert "Make DODAG ID selection RFC 6550-compliant"
 2 files changed, 18 insertions(+), 14 deletions(-)
cmignanti@cmignanti-asus:~/code/contiki/examples/ipv6/rpl-border-router$ make
using saved target 'cc2538dk'
  CC        ../../../cpu/cc2538/./ieee-addr.c
  AR        contiki-cc2538dk.a
  CC        ../../../cpu/cc2538/cc2538.lds
  CC        ../../../platform/cc2538dk/./startup-gcc.c
  CC        border-router.c
  LD        border-router.elf
arm-none-eabi-objcopy -O ihex border-router.elf border-router.hex
arm-none-eabi-objcopy -O binary --gap-fill 0xff border-router.elf border-router.bin
cp border-router.elf border-router.cc2538dk
rm obj_cc2538dk/startup-gcc.o border-router.co
cmignanti@cmignanti-asus:~/code/contiki/examples/ipv6/rpl-border-router$ arm-none-eabi-size border-router.elf
   text    data     bss     dec     hex filename
  46804     505   10160   57469    e07d border-router.elf

[claudyus]

The problem was due to the flash program that I used.

Probably the firmware was corrupted at upload time by the programmer (https://github.com/1248/cc2538-prog), using the suggested one cc2538-bsl anythink work as aspect.