CJ Shaw

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

7 years, 9 months ago.

nRF51822 keeps crashing after random duration. Possible memory problem?

Hi. I have a bug that is proving difficult very difficult for me to solve but I think is due to low-memory / memory leak:

I have an application for the nRF51822 that polls various peripherals (SPI, I2C etc.) and feeds data to various BLE services. I currently have 4 BLE services amounting to 15 characteristics in total (possible near upper limits?).

There are two possibly distinct issues:

1. When running on nRF51-DK (that uses nRF51422 with 32kB SRAM) the application runs & connects fine. However after subscribing to all relevant characteristics with an iOS app the app will randomly crash between 3-7mins of runtime. The soft device appears to remain active as no "disconnection" occurs but the device is unresponsive to application-level functions. Is this probably due to memory allocation problems or a memory leak? Or is there something fundamentally difficult about using this many ble services with constant updating of data?

2. When trying to run the same code on an nRF51822 module (using the correct compilation target) the code, with all 4 BLE services, crashes before even reaching the advertising stage. When I remove one (or more) services it manages to start properly and I can even connect, but now the same random crash as above will usually occur in a similar timeframe. This symptom a main reason I believe this is a memory issue.

Other than general advice on what to look for here some questions are:

  • Does this look like a memory-related issue as I believe?
  • Is it really best to allocate Ble services to heap memory with the "new" command as is done in all BLE examples?
  • Do I not need to do anything special to prevent memory leaks here? Is there a chance the stack & heap will collide and cause this kind of crash (where the soft device appears to remain alive)?

Update: Done lots of memory allocation checking as per things mentioned in this thread (and the one it links to): https://developer.mbed.org/questions/5906/NRF51822-Heap-can-not-be-fully-used/

Problem 2 is almost certainly memory problem as it's just getting overloaded. Can solve this either by "tricking the compiler" to allow bigger heap/stack as mentioned in the link above. Or just trying to save memory in other ways.

Problem 1 is not memory related as memory allocation is working fine in my code. Also failure mode of memory overload is for the whole thing to crash whereas now the BLE stays "alive". This problem sounds exactly like this: https://github.com/mbedmicro/mbed/issues/1378

Having multiple ticker objects on the nRF51822 results in problems exactly like i'm experiencing. Basically the tickers may collide (after random duration) and result in all application interrupts being killed. Hence why it doesn't completely crash.

I'm re-writing code to test this out and will update later.

posted by CJ Shaw 06 Jul 2016

1 Answer

Vincent (pan-) Coubard
7 years, 7 months ago.

Quote:

Having multiple ticker objects on the nRF51822 results in problems exactly like i'm experiencing. Basically the tickers may collide (after random duration) and result in all application interrupts being killed. Hence why it doesn't completely crash.

From what I see in the mbed code base, the ticker use extensively core_util_critical_section_enter and core_util_critical_section_exit which are not softdevice aware in the current form. That might be the cause of your troubles, blocking all interrupt is not allowed by the softdevice and the ticker functions can takes a lot of time.

One way to test it would be to use the functions in this file: https://github.com/ARMmbed/core-util/blob/master/source/critical_nordic.c

Which are softdevice aware.