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]

Thanks for you answer !

Currently we can not reproduce the issue with the log (it's very difficult to reproduce), but we are still trying.

On the application side, everything is blocked (software-blinking leds stopped for example - even if PWMs are still active) - without a reset.

Thanks about the softdevice_fault_handler.

But as far as I can see, softdevice_fault_handler or other faults will generate a reset (I did not changed app_error_fault_handler, and I'm not in DEBUG) - and it's not the case here.

Have you ever heard about a possible crash or infinite loop during the Discovering services on the periph side ? It may be linked to a bonding process (bonding should not append, but it's not forbidden and not correctly managed either) and/or a cold start (it seems for us easiest to reproduce the issue after a cold start) and/or a possible notification send (at the same time ?)

We are thinking about an issue there because logs from nrfconnect seems to show a time out on the discovering services request :

V	17:49:23.129	Connecting to EA:A3:51:3B:C8:AB...
D	17:49:23.130	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	17:49:23.625	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	17:49:23.640	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	17:49:23.640	Connected to EA:A3:51:3B:C8:AB
V	17:49:23.640	Discovering services...
D	17:49:23.640	gatt.discoverServices()
I	17:49:23.965	Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
D	17:49:29.145	[Callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
I	17:49:29.145	Disconnected
D	17:49:29.173	[Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

Regards,

Julien

[Hung Bui]

Hi Julien, 
No, not really. The softdevice S130 is pretty robust and it's been using in millions of devices for many years (almost 10 years). I am not aware of any report about the softdevice being crashed and keep the CPU in an infinite loop, no. If there is any crash, it would either throw a fault or go straight to a hardfault and reset. 

Regarding the log, it seems that the connection is terminated before discovery completed but it's hard to tell what exactly wrong here. If you can capture a sniffer trace when the issue happen it would be very useful.