Using:
- nRF51822 (nRFgo starterkit with nRF6310 and PCA10005)
- Softdevice s110 version 6.0
- Nordic Sdk 5.2.0
- Compiled with GCC 4.8 using pure-gcc setup
I have some automated Ble tests, were a Android central connects the nRF51822 peripheral 10 times, were for each connection session the tests are performing some different e.g. gatt communication.
Sometimes within the tests, the nRF51822 peripheral locks up and doesn't respond anymore (within a connection state).
I'm testing against some different Android central devices and this time I'd seen this behavior only when communicating with an Inforce Devboard as central.
I'd attached a Segger JLink wit gdb and tried to see what's going wrong:
$ /opt/gcc-arm-none-eabi-4_8-2014q2/bin/arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140529-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <gnu.org/.../gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<www.gnu.org/.../>.
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0x0000267a in ?? ()
(gdb) backtrace
#0 0x0000267a in ?? ()
#1 0x00001d24 in ?? ()
#2 0x00001d24 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Because of the stacktrace addresses are all in the softdevice range, I think that's a softdevice problem.
Maybe, I could provide some logfiles from Android hci snoop and nRF51822 debug output (if you think that it may help to find the problem).
