8 years, 9 months ago.

Possible memory bug with new BLE api on nrf (Arch BLE)

Was working with BLE without much issue before the change over last week, but when I refactored my code to match the new BLE library I bumped into all sorts of trouble. Mainly I was having the BLE disconnect and the chip lock up when trying to write to a characteristic under some seemingly random circumstances. After much testing and removing of variables I found the stack and BLE functions to work well alone, but when I added my OLED module back in things locked up again. The OLED should take 1k of RAM for its buffer at 128x64 pixels, but strangely if I init the OLED at 128x32 everything works fine. Up the buffer to 128x64 and BLE never gets started. While it seems like some kind of memory issue, there should be plenty of RAM available as there is basically nothing happening in my testing program.

I'm wondering if there could be an issue with the memory addresses for the buffer bumping into the soft device or something else more nebulous. My test code is here, it fires up and works but when you hop into the SSD1306.h and set the display size to 128x64 it will freeze. Any advice or things to check are appreciated.

https://developer.mbed.org/users/dmccloud/code/BLE_ERROR_TEST/

When running this OLED library along with other libraries to drive LEDs everything worked fine when there was no BLE and thus no soft device so its definitely some clashing of my code and the soft device.