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, 

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. 

[Julien Cosmo]

We are trying to reproduce with debug and/or logs, but it's very difficult, and we didn't managed so far.

One tip: we were able to reproduce the issue with all notifications deactivated. So it seems it's not linked to notifications. And the trace show exactly the same stop in the the same service request.

One question : do you think that an issue in the stack allocated size may produce this kind of crash ? Due to ram limitation (we are pretty full on RAM side), we needed to reduce the stack size compare to previous firmware version.

Also here is the sdk config we used, I don't know if this could help : 7635.sdk_config.h

We are wondering if HCI_MEM_POOL_ENABLED set to 0 may have a link to our problem.

Another question : Where can I find more details on what's happening during the service discovery process ?

Thanks again !

Julien

[Hung Bui]

Hi Julien, 
Could you give the exact call stack configuration you have in your project  ? 
S130 requires at least 1536 bytes. The stack configuration in your project is shared between softdevice and application. So it also depends on how many bytes your application using. Have you tried to reduce heap and increase stack ? 
By default we don't use HCI mem pool in most of our examples so I don't think it's an issue. I assume you don't use it in your application ? 

[Julien Cosmo]

Thanks !

The current configuration is (only) 1280 bytes for the stack size. We are also testing a new version with 1792 bytes (it's difficult to go further, we use a lot of RAM, but we can't reproduce on this version so far). Our previous firmware had 2KB.

We do not use heap (set to 0)

So it may be the root cause of our crash ?

[Hung Bui]

Hi Julien, 
It could be the root cause. I wouldn't give just 1536 bytes but slightly more, maybe 2kB. You may want to run some memory analysis to know how much application's stack required.  For example: https://www.segger.com/products/development-tools/embedded-studio/technology/code-analysis/#stack-usage