Product crash with nrf51822 peripheral s130 2.0.1 : how to get logs or more information ?

[Julien Cosmo]

Dear Mr/Mrs,

Our commercialized product currently have a default: some (luckily rare) clients get a crash after the 1st configuration - sometimes hours after but always while being connected. The product is totally blocked, and need a hard reset to work again. After the reset, it seems there is no problem any more.

It's very difficult to reproduce in our side. Our hypothesis on the crash goes from a (rare) stack size issue to a cold start specific one. It could also be an unwanted bonding.

Anyway, is there a way to get some interesting logs from the softdevice ? (as there seems to be no more BLE activity after the crash, we guess that it happens at the softdevice level, not in the application side). NRF logs (using uart) returns only assert and softdevice configuration issues from the sdk, as far as I can see.

And if you have any suggestions or ideas to get more information about this crash...it would be much appreciated !

Best regards,

Julien

[Hung Bui]

Hi Julien, 

Do you see anything in the log ? Was the application continue to work (without BLE) after the fault happened  ?

In most case if the softdevice crash or has a fault it will call the softdevice_fault_handler() function with the info and fault ID about the fault. 
You may need to define  app_error_fault_handler() so that it overwrite the weak declaration in the app_error_weak.c if you want to print more log. But if you can reproduce the issue you can just put a breakpoint inside app_error_fault_handler() in app_error_weak.c.

If you have a look inside nrf_sdm.h you can find NRF_FAULT_ID_SD_RANGE_START it's where the fault ID for softdevice start. 

[Julien Cosmo]

I'm more thinking about a bad parameter we send to the softdevice... Or a race condition somewhere. But it's still very unclear to me.

Here is a sniffer trace we just manage to get ! 

capture crash ride.pcapng

After a series of connection/restart, the last command send by nrfconnect (at the end of the file) seems to be: 

6743 1148.847139 Master_0xaf9a959f ATT 37 Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x000c..0x0013 Slave_0xaf9a959f

There is no answer, and the peripheral device is then totally blocked.

[Hung Bui]

Hi Julien, 

Thanks for the sniffer. Yes it looked like a crash right after a read by type request. But what causing this we don't know. 
If you managed to find a way to reproduce the issue please try to debug and check the log. 

You can also take more sniffer trace with a central that you have more control over (for example nRF Connect Dekstop on PC or nRF5 as a central) so that you can control when you want to do service discovery. By having that we can be sure if it was because of service discovery or not. 
Usually service discovery is handled by the softdevice and should not cause any issue.