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.
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.
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.
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.
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?
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?
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.
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?
I can't get CPU registers today until I get my new JLINK. I'm using the SEGGER (Microsoft) IDE and GNU compiler. I'll work on abstracting the important code so I don't have to post the whole thing as there's lots of stuff with I2C that are a distraction.
Here's an abstraction of the code - this compiles but doesn't load due to setup problems.
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <nrf.h>
#include <nrfx_timer.h>
#include <nrf_sdh.h>
static nrfx_timer_config_t timerCheckinConfig =
{.frequency = NRF_TIMER_FREQ_500kHz,
.mode = NRF_TIMER_MODE_TIMER,
.bit_width = NRF_TIMER_BIT_WIDTH_32,
.interrupt_priority = NRFX_TIMER_DEFAULT_CONFIG_IRQ_PRIORITY,
.p_context = NULL};
typedef struct {
nrfx_timer_t inst;
uint32_t ms;
uint32_t ticks;
uint32_t running;
uint32_t sinceFlashReset;
} Metronome;
Metronome timerCheckin =
{.inst = NRFX_TIMER_INSTANCE(2),
.ms = 2,
.ticks = 0,
.running = 0,
.sinceFlashReset = 0 };
void timerCheckinEventHandler(nrf_timer_event_t etype, void* pContext)
{
switch( etype ) {
case NRF_TIMER_EVENT_COMPARE2: break;
default: break;
}
}
void timerInit(void)
{
nrfx_err_t rc;
rc = nrfx_timer_init(&timerCheckin.inst, &timerCheckinConfig, timerCheckinEventHandler);
APP_ERROR_CHECK(rc);
timerCheckin.ticks = nrfx_timer_ms_to_ticks(&timerCheckin.inst, timerCheckin.ms);
nrfx_timer_extended_compare(&timerCheckin.inst,
NRF_TIMER_CC_CHANNEL2,
timerCheckin.ms,
NRF_TIMER_SHORT_COMPARE2_CLEAR_MASK,
true);
nrfx_timer_enable(&timerCheckin.inst);
}
void ble_stack_init(void)
{
ret_code_t err_code;
err_code = nrf_sdh_enable_request();
// At this point err_code == 3!
APP_ERROR_CHECK(err_code);
}
int main(void)
{
timerInit();
ble_stack_init();
}
Jed Marti said:this compiles but doesn't load due to setup problems.
Is it related to debugger setup, or are you able to load and debug the original project? The nrf_sdh_enable_request() should not return 0x3 and it doesn't make any calls nrf_atfifo_item_alloc() either.
I will try to run this on a nordic DK if you upload the full project (the simplified version without i2c) as a zip file.