We have an application that sends a short BLE packet to a mobile app every second, for about 15 minutes, and then shuts down and sleeps. Meanwhile, it also writes to an SPI flash and accesses various I2C devices. The firmware uses FreeRTOS and runs 8 to 10 tasks. After extensive testing with thousands of runs, we find that 15% of the time, units do not finish. Running with RTTviewer, we can't see anything unusual -- the units just stop. It doesn't look like either the stack over or general fault handler are called. The error rate *seemed* to depend somewhat on which unit we tested (we tested approximately 25 units, hundreds of runs each).
We finally figured out the "fix" was to move from SoftDevice 132 version 5.0.0 to version 5.1.0 -- at which point the problem virtually disappeared.
There is nothing in the 5.1.0 release notes that jumps out at us as a bug that was fixed that would account for the change in error rate. We are using short, conventional packets with 20 bytes of data payload, and after BLE initialization, we never change it. We are using conventional, non-secure initialization/handshake. The units may run for 5 or 10 or 12 minutes and then fail.
We *seem* to have fixed our problem by moving to 5.1.0 SD 132, but it would be comforting to have some idea what the problem was so we can fix it altogether.
BTW, we are using nRF5_SDK_14.2.0_17b948a.
One possible symptom: When we have the JLINK adapter attached and are running RTT Viewer, occasionally the firmware will appear to freeze, and RTT Viewer will rapidly repeat the same 30 lines of output over and over endlessly -- about 1200 characters.
