nRF5 SDK 16 BLE startup, failing nrf_atfifo_item_alloc

[Jed Marti]

During BLE startup call to nrf_sdh_enable_request(), nrf_atfifo_item_alloc fails and returns NULL causing a hard fault.

This sounds like an sdk_config.h problem but I don't know where to start looking.

[Vidar Berg]

Hello,

Is the failing call to nrf_atfifo_item_alloc() being made by a SDK module or by your own code? NULL is usually handled by returning NRF_ERROR_NO_MEM back to the app, which should not lead to a fault exception. I would suggest  to first try enabling the HardFault handling library in your project and see if it could help you find out exactly where the fault occurred.

[Jed Marti]

That's how I found out. The top level call is nrf_sdh_enable_request() from the examples which is the first call in ble_stack_init. This call chain hard faulted as a result of NULL being returned by nrf_atfifo_item_alloc. nrf_sdh_enable_request then failed with code 3 which causes the hard stop.

[Vidar Berg]

Is the program hitting the breakpoint inside  app_error_weak.c::app_error_fault_handler()? nrf_sdh_enable_request() should never return 0x3 as far as I can tell. Do you have the debug log for this?

[Jed Marti]

I don't have the serial port enabled, just running the SEGGER debugger. Due to COVID 19, I'm now working from home and don't yet have access to the debugger.

The halt is a branch instruction to itself, I'm not sure where, it could be the SEGGER startup code but it's definitely caused by return code 3 on nrf_sdh_enable_request() and the following APP_ERROR_CHECK.

[Vidar Berg]

You can enable RTT logging if you want debug messages through the debugger. Can you post the CPU registers when it's halted? Are you debugging this in an IDE?