Failure in ble_stack_init during startup

RE: Failure in ble_stack_init during startup

SteveHx — Fri, 19 Jun 2026 01:23:26 GMT

How do I go about that? Any time I run the debugger, it resets the code to the start of main(), and stepping or just running from there runs flawlessly. Apparently you know some new and very useful trick I need to learn.

RE: Failure in ble_stack_init during startup

Vidar Berg — Thu, 18 Jun 2026 10:05:05 GMT

that is exactly why I am suggesting you attach the debugger to the running target after the reset has occurred.

RE: Failure in ble_stack_init during startup

SteveHx — Thu, 18 Jun 2026 10:02:48 GMT

That's no help because the reset doesn't occur if run with the debugger. I already record RESETREAS into NV memory right at hte beginning of main(), and it's all zeroes in the failure case. ?!?!?

RE: Failure in ble_stack_init during startup

Vidar Berg — Thu, 18 Jun 2026 06:38:27 GMT

It sounds like this reset may occur even if you only have a busy wait loop in main(), which does point to a HW problem if true. We should try to confirm the reset source. To do that, please remove the part of your code that clears RESETREAS as suggested earlier, and instead read the RESETREAS value directly using your debugger. This avoids relying on the application to capture and store the register value correctly. You can use nrfjprog or nrfutil from the command line to read out the register after the reset has occurred.

# Read out POWER->RESETREAS 
nrfjprog --memrd 0x40000400
nrfutil device read --address 0x40000400 --direct

Regarding the build code difference, please have a look at the PCN here: https://nrfconnectdocs.nordicsemi.com/pdf/PCN/pcn_106_v1.0.pdf. It's the same silicon. It's just that it's tested and assembled at different locations.

RE: Failure in ble_stack_init during startup

SteveHx — Wed, 17 Jun 2026 20:27:26 GMT

I have been experimenting with different delays near the beginning of main(), before calling any of the BLE initialization. With no delay, or with a null for() loop of 10000 cycles, a reset happens sometime after calling sd_softdevice_enable() and before it returns. If I increase the for() loop to 20000 or higher (up to 10000000), it seems to reset before the loop completes.

There's got to be some fundamental difference between nRF52832QFAAE0 and the E1 variant. Here's what we know about the various programming methods, what works and what doesn't:

Method E0 E1

Drag&drop Works Works
Powerup Works Fails
Build&debug Works Works
Build&run Works Fails

The critical thing is being able to run from powerup. Same firmware, same schematic and PCB layout in the area of the processor, same hex image, E1 fails at the call to sd_softdevice_enable().

RE: Failure in ble_stack_init during startup

SteveHx — Wed, 17 Jun 2026 20:10:47 GMT

Thank you for the clarification on LFCLK. It appears that everything there works as it should, now that I understand it.

I had tried previously experimenting along the lines you suggest, with changing the timing vs. startup of the BLE initialization. I was very rushed getting out the door this morning but I saw something (

that I need to go back and find) suggesting that's the answer.

Is there any relevant difference between the E0 and E1 variants of the nRF52832QFAA?

I'm guessing you're just leaving, if not already out the door for today. So have a good evening and look for some more info from me in the morning. Tomorrow I'm gone pretty much all day, except for a brief window in the office around 0530-0630 EDT (0930-1030Z).

RE: Failure in ble_stack_init during startup

Vidar Berg — Wed, 17 Jun 2026 12:45:23 GMT

[quote user="SteveHx"]Starting LFCLK works MUCH better that way! (suprise, surprise!) But when bit 16 of LFCLKSTAT goes high, the LSBs are all zero, indicating that it's running the RC clock rather than the xtal clock I requested.[/quote]

The clock will start running from the RC oscillator after the start task is triggered while waiting on the crystal oscillator to ramp up. So you must wait on the LF clock started event before checking the status register to determine whether the crystal oscillator was able to start or not.

    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_LFCLKSTART = 1;
    while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);
    //code will not reach this point if LFXO fails to start

Also, it can be problematic to start the oscillator with one source and then have the softdevice select a different source in sd_softdevice_enable(). That was the reasonI suggested removing your test code and instead test with different softdevice clock configurations in my previous reply.

[quote user="SteveHx"]which is called from ble_stack_init() which is called early in main(). So what is different about the way it resets from drag&drop programming vs. how reset works from power up?[/quote]

I can't think of any relevant differences here and I think we are really missing enough concrete information about the failure to make meaningful guesses. It would be better if we could first confirm what is actually failing after a cold boot. Perhaps it could be that the external memory fails to get ready in time after a power up.

You could try adding a few endless loops at different points in main() and do some test iterations where you remove the loop one by one down until you find the point it is no longer reached or start going in a boot loop.

    CRITICAL_REGION_ENTER();
#ifdef ANT_LICENSE_KEY
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler, ANT_LICENSE_KEY);
#else
    ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);
    if(ret_code != NRF_SUCCESS) 
    {
        for(;;);
    }
#endif

RE: Failure in ble_stack_init during startup

SteveHx — Wed, 17 Jun 2026 10:15:41 GMT

Starting LFCLK works MUCH better that way! (suprise, surprise!) But when bit 16 of LFCLKSTAT goes high, the LSBs are all zero, indicating that it's running the RC clock rather than the xtal clock I requested.

And with LFCLK running, I'm getting some other funny behavior that I need to investigate further.

void CheckLfClock (void)
{
char Str [80];
sprintf (Str, "LFCLKSTAT %08X", NRF_CLOCK -> LFCLKSTAT);
LogToJournal (Str);
}

void StartLfClock (void)
{
LogToJournal ("Starting LF Clock");
NRF_CLOCK -> TASKS_LFCLKSTOP = 1;
NRF_CLOCK -> LFCLKSRC = 1;
NRF_CLOCK -> TASKS_LFCLKSTART = 1;
}

void AwaitLfClock (void)
{
int i;
char Str [80];
for (i = 1000000; i; --i) if (NRF_CLOCK -> LFCLKSTAT) break;
sprintf (Str, "%d tries remaining", i);
LogToJournal (Str);
}

I will have to drop offline shortly and won't be back in the office till after your work hours, both today and tomorrow. I'm hoping you can illuminate what's different about the reset upon drag&drop programming vs. power up.

RE: Failure in ble_stack_init during startup

SteveHx — Wed, 17 Jun 2026 09:48:25 GMT

[quote userid="4240" url="~/f/nordic-q-a/128335/failure-in-ble_stack_init-during-startup/568035"]Note that a task is triggered by writing 1 to the TASK register. The code above is not writing anything to the register.[/quote]

Doohhhhhh.... I knew that! (He says while peeling egg from his face!) And here we see why it's really helpful to have a second person look at my code!

Back to the issue at hand. Only item 3 above is still a problem. If I program with drag&drop, everything runs fine. But even after programming that way and later power cycling, the system appears to reset when sd_softdevice_enable() is called from within nrf_sdh_enable_request() which is called from ble_stack_init() which is called early in main(). So what is different about the way it resets from drag&drop programming vs. how reset works from power up?

RE: Failure in ble_stack_init during startup

Vidar Berg — Wed, 17 Jun 2026 09:08:44 GMT

The observations you have described do not indicate an LF clock issue. If I have understood you correctly, these are the three problems you have observed:

Failure in advertising_init() with NRF_ERROR_NO_MEM.
NRF_ERROR_INVALID_STATE returned from sd_softdevice_enable() (again, this is expected on the first run when using Build & Run, unless you still have my run_reset_handler_once() test function at the start of main()).
A sudden reset with an unconfirmed reset source occurring somewhere in ble_stack_init().

However, it is unclear to me under which conditions these issues occur and when they do not. To find the root cause and narrow down the problem, we first need to understand exactly what the error is.

If you still want to test with the LF RC oscillator, you can remove the test code you posted, and instead apply the following changes to the Softdevice clock configuration in sdk_config.h:

[quote user="SteveHx"]void StartLfClock (void)
{
LogToJournal ("Starting LF Clock");
NRF_CLOCK -> TASKS_LFCLKSTOP;
NRF_CLOCK -> LFCLKSRC = 1;
NRF_CLOCK -> TASKS_LFCLKSTART;
}[/quote]

Note that a task is triggered by writing 1 to the TASK register. The code above is not writing anything to the register.

RE: Failure in ble_stack_init during startup

SteveHx — Tue, 16 Jun 2026 21:37:44 GMT

I just discovered that the working boards were built with the nRF52832QFAAE0, while the boards that fail have the E1 variant. Extensive searching online did not reveal any relevant differences. Can this be the whole problem?

RE: Failure in ble_stack_init during startup

SteveHx — Tue, 16 Jun 2026 15:05:38 GMT

Further info. On speculation that the 32 KHz clock could be a problem, I tried the other selections for LFCLK.

Set to 2 (synthesized from the 64 MHz clock) the behavior is identical. If started via drag&drop, it runs fine; started via F5 or power cycle it gets stuck in a reset loop in sd_softdevice_enable().

Set to 0 (RC clock) it fails to start up under any conditions, presumably because the required external components are not present.

So, if the 32 KHz oscillator is off the hook, what other minor ("trivial") difference could cause the behavior I'm seeing?

Is there a way to send you screenshots of the relevant schematic and layout areas?

RE: Failure in ble_stack_init during startup

SteveHx — Tue, 16 Jun 2026 11:02:13 GMT

I have tried to start up the LF clock with the following routines, before any calls into the softdevice. It does not start up on either board, but after a correct startup (any method on the old rev, or via drag&drop on the new boards), it always shows running. I speculate that there's some problem in the softdevice starting the clock, but how to find it?

void CheckLfClock (void)
{
char Str [80];
sprintf (Str, "LFCLKSTAT %08X", NRF_CLOCK -> LFCLKSTAT);
LogToJournal (Str);
}

void StartLfClock (void)
{
LogToJournal ("Starting LF Clock");
NRF_CLOCK -> TASKS_LFCLKSTOP;
NRF_CLOCK -> LFCLKSRC = 1;
NRF_CLOCK -> TASKS_LFCLKSTART;
}

void AwaitLfClock (void)
{
int i;
char Str [80];
for (i = 1000000; i; --i) if (NRF_CLOCK -> LFCLKSTAT) break;
sprintf (Str, "%d tries remaining", i);
LogToJournal (Str);
}

I also tried clearing SOFTDEVICE_RESET_HANDLER_EXECUTED after recording its value and before the call to the softdevice, thinking I could at least trap any reset occurring there. No joy.

RE: Failure in ble_stack_init during startup

SteveHx — Mon, 15 Jun 2026 21:31:42 GMT

Confirming again, even with your added "run once" reset code: If started from a drag&drop, it runs exactly as expected. If started from F5 (default is Build&Run in SES, which is how I left it), or from a power cycle, it gets to the call to sd_softdevice_enable() in the CRITICAL_REGION in nrf_sdh_enable_request() and resets somewhere before it returns from that call. I know this can't be, but somewhere in this house of cards hides a joker....

RE: Failure in ble_stack_init during startup

SteveHx — Mon, 15 Jun 2026 14:29:50 GMT

I'm not sure that would cause the continuous resets I'm seeing, but that's just the code I needed to test for a proper reset. Will run and get back to you shortly.

RE: Failure in ble_stack_init during startup

Vidar Berg — Mon, 15 Jun 2026 13:20:03 GMT

F5 has always been assigned to "Debug->Go" on my setups (linux, macOS, and Windows with SES v5.x), hence my assumption that you were starting a debug session. "Debug->Go" is equivalent to "Build -> Build&Debug". Either way, thanks for clearing this up.

I would say the expected failure mode for an LF clock issue is either that the program hangs forever inside sd_softdevice_enable() because the oscillator fails to start, or BLE connectivity issues due to frequency drift. What it cannot do is cause the invalid state error you are seeing.

I'm still convinced that the issue is that the softdevice's reset handler was skipped during boot. Again, this is expected and a known limitation when using build&run. I do not know why you have not experienced this before with other boards, but the problem can easily get masked as I mentioned earlier. If you want to test for this hypothesis you can add the code below temporary to your project.

#define RESET_HANDLER_ADDR (*(volatile uint32_t *) 0x4)
#define SOFTDEVICE_RESET_HANDLER_EXECUTED 0xAA

typedef void (*reset_handler_t)(void);

static void run_reset_handler_once(void)
{
    if (NRF_POWER->GPREGRET == SOFTDEVICE_RESET_HANDLER_EXECUTED)
    {
        /* Already ran fon af previous reset — skip */
        NRF_POWER->GPREGRET = 0xFF;
        return;
    }

    /* Mark it before jumping, in case reset handler doesn't return */
    NRF_POWER->GPREGRET = SOFTDEVICE_RESET_HANDLER_EXECUTED;

    ((reset_handler_t)(RESET_HANDLER_ADDR))();
}

/**@brief Function for application main entry.
 */
int main(void)
{
    /* For debugging purposes - manually invoke the MBR->Softdevice's reset handler */
    run_reset_handler_once();

RE: Failure in ble_stack_init during startup

SteveHx — Mon, 15 Jun 2026 12:59:14 GMT

Probing the idea of the LF clock further. On a board that starts up fine from F5 or power up, I sample LFCLKSTAT early in the startup - all zeroes. I attempt to start it with

NRF_CLOCK -> TASKS_LFCLKSTOP;
NRF_CLOCK -> LFCLKSRC = 1;
NRF_CLOCK -> TASKS_LFCLKSTART;

And then test LFCLKSTAT up to 1 million times, always zero. On the good board, proceeding thru the BLE initialization and then testing LFCLKSTAT yields the expected 00010001. So I seem to have added another mystery: Why can't I start the clock? And the fact that it hasn't started prior to calling ble_stack_init() doesn't seem to be a problem. But if ble_stack_init() can't get it started, that could be the source of the hangups / resets on the new rev board.

Am I at all close here?

RE: Failure in ble_stack_init during startup

SteveHx — Mon, 15 Jun 2026 10:24:58 GMT

Nothing inconsistent except the assumption that by F5 I mean Build&Debug. F5 on SES is Build&Run. To summarize:

If run via drag&drop firmware loading, it runs fine for hours.

If run via F5 (Build&Run), or if run from a power cycle, it resets continuously.

When I trigger an erase of my external NV memory via a BLE command, the last step is to do NVIC_SystemReset, and that reset results in a successful run.

If I could get it to run from power-up, I'd be done.

Running identical firmware on a previous rev board does not result in these resets, so clearly there's some hardware difference. Is it possible that a reset could be caused by the 32 KHz oscillator not yet being up and stable at the call to start up BLE? I'm well aware that the osc is sensitive to loading, so directly probing with my scope is not conclusive. How best to determine if the 32 KHz osc is running, via some section of the chip I can access in my code?

RE: Failure in ble_stack_init during startup

Vidar Berg — Mon, 15 Jun 2026 06:41:14 GMT

The inconsistencies are making it difficult to troubleshoot this issue. For example, earlier you indicated that the problem did not occur while debugging:

[quote user="SteveHx"]If run with Build and Debug, it runs fine[/quote]

But now it fails advertising_init() with NRF_ERROR_NO_MEM, or in sd_softdevice_enable() with NRF_ERROR_INVALID_STATE.

[quote user="SteveHx"]I have also added probes that show that the reset is coming from the call to sd_softdevice_enable(), but that is probably just a symptom of the soft device not being properly started above[/quote]

The softdevice call can return an error code, but it cannot trigger a system reset. Assuming this function is only called once during startup, the only reason it can return NRF_ERROR_INVALID_STATE is that the softdevice's reset handler was not executed during the boot sequence due to the debugger.

Please confirm that you have the following debugger setting in your project configuration

Just to illustrate, here is what it looks like if I enable this setting on my side:

Crash log if I let it run to error handler:

If I place a breakpoint at the line number reported by the crashlog:

And when I step into the nrf_sdh_enable_request() function:

[quote user="SteveHx"]The system starts up fine from either loading firmware via drag&drop or from a programmed NVIC_SystemReset[/quote]

I assume you are calling NVIC_SystemReset() from your error handler, since the device is entering a boot loop. In that case, any runtime error should have causes the device to recover from this state.

RE: Failure in ble_stack_init during startup

SteveHx — Sun, 14 Jun 2026 21:09:30 GMT

Some more digging:

Per the above, the first time in from a startup via either power cycle or SES F5, both nrf_sdh_enable_request() and nrf_sdh_ble_enable() return an error code of 8, and sometime after, the error handler gets called with the report above - no pc, nothing to indicate from what it was called.

I have also added probes that show that the reset is coming from the call to sd_softdevice_enable(), but that is probably just a symptom of the soft device not being properly started above. Once it happens, though, I get continual resets, entering nrf_sdh_enable_request() and crashing with a reset in sd_softdevice_enable() every time.

I'll be asleep when you come in to work this morning (Monday) as we're 6 hours behind you. But I should be online by about noon your time.

RE: Failure in ble_stack_init during startup

SteveHx — Sun, 14 Jun 2026 11:30:19 GMT

Bottom line is:

The system starts up fine from either loading firmware via drag&drop or from a programmed NVIC_SystemReset. If started from a powerup or from SES pressing F5, it resets somewhere inside the CRITICAL_REGION within nrf_sdh_enable_request(). The only code that could do that is in either CRITICAL_REGION_ENTER(), sd_softdevice_enable(), or CRITICAL_REGION_EXIT(). Those routines tinker heavily with various interrupt flags. Is it possible that some kind of timing or race condition could be causing this?

RE: Failure in ble_stack_init during startup

SteveHx — Sat, 13 Jun 2026 23:20:44 GMT

The debugger is so cumbersome as to be completely useless with a softdevice. Hence I have devised my own debugging methods. I have nonvolatile memory available, and a mechanism whereby to record any events of interest, even in a failure to start, such that subsequently getting a successful startup allows me to read the whole history. Very flexible, with recording of whatever plain text is most illuminating for the problem being diagnosed, and it works quite well.

I have added code within app_error_fault_handler() to record all the details if that handler is called. I just now ran another complete test:

1) Boot properly via drag&drop, run erase command on NV memory.
2) Boot via SES F5, observe LED showing repeated resets.
3) Boot properly via drag&drop, download saved journal.

I could send the full journa/, but probably more useful to summarize.

1st boot (1 above) is shown properly.

2nd attempt, using F5:
Starts up, gets thru services_init() in main(), then crashes somewhere in advertising_init() with the following message:

Fault 00004001 00000000 2000FE8C ERROR 4 [NRF_ERROR_NO_MEM] at (null):0
PC at: 0x00000000

The above message was formatted by these two lines (in the fault handler). Infotext does just what's expected; these two sprintf's are physically in different routines:

sprintf (InfoText, "ERROR %u [%s] at %s:%u\r\nPC at: 0x%08x",
p_info->err_code,
nrf_strerror_get(p_info->err_code),
p_info->p_file_name,
p_info->line_num,
pc);
sprintf (Str, "\r\nFault %08X %08X %08X %s\r\n", id, pc, info, InfoTxt);

Thus the values are:

id - 00004001
pc - 00000000 (?!?!?)
info - 2000FE8C
err_code - 4
err_string - NRF_ERROR_NO_MEM
file_name - null
line_num - 0
pc - 00000000

So clearly something went off the rails badly.

Next the system reboots, and gets as far as calling nrf_sdh_enable_request() from within ble_stack_init(). This drills down to nrf_sdh_enable_request(), which runs to a print just prior to the CRITICAL_REGION, and then reboots from within the CRITICAL_REGION. The only thing called from within there is sd_softdevice_enable(), so the reboot is happening from inside the softdevice. Recall that this is after the above no-memory error.

From here, it repeatedly reboots and crashes in the CRITICAL_REGION until I intervene and cause a correct reboot via drag&drop in order to read out the record.

Are you as baffled as me yet?!?

RE: Failure in ble_stack_init during startup

Vidar Berg — Fri, 12 Jun 2026 16:02:03 GMT

The limitation when debugging with the softdevice is that you generally cannot continue execution after halting the CPU (for example, when hitting a breakpoint), as the softdevice will detect that it has failed to meet its timing requirements and trigger an error (app_error_fault_handler() is called with id=NRF_FAULT_ID_SD_ASSERT). But I don't see why this should be a problem here.

In any case, based on what you said earlier, the problem is not reproducible in debug mode. So you would need to use nrfjprog --memrd <register address> from the command line or similar approach to read the register from the running target after the problem has occurred. The challenge with this here is that you may end up reading the register after it has already been cleared by your FW. So I suggest commenting the NRF_POWER -> RESETREAS = ResetReason; line first, then see if it still reads as 0 when it is going in the boot loop.

[quote userid="68828" url="~/f/nordic-q-a/128335/failure-in-ble_stack_init-during-startup/567853"]n nrf_sdh_enable_request(), it's resetting in this critical region:[/quote]

There is nothing that can lead to NVIC_SystemReset() being called within this function. You can search through your project for NVIC_SystemReset() to see if is called in any other places than the error handler to verify.

[quote userid="68828" url="~/f/nordic-q-a/128335/failure-in-ble_stack_init-during-startup/567851"]I added the code you suggested above, and never got it to output (never reached).[/quote]

Does this mean that you have redefined the app_error_fault_handler() in your project? The picture I posted is showing the default handler used in the SDK examples.

I will be signing off now (I'm based in Norway, so I'm a few hours ahead), but I hope you will be able to gather some more concrete debugging evidence of what is happening.

RE: Failure in ble_stack_init during startup

SteveHx — Fri, 12 Jun 2026 15:25:34 GMT

In nrf_sdh_enable_request(), it's resetting in this critical region:

CRITICAL_REGION_ENTER();
#ifdef ANT_LICENSE_KEY
ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler, ANT_LICENSE_KEY);
#else
ret_code = sd_softdevice_enable(&clock_lf_cfg, app_error_fault_handler);
#endif
m_nrf_sdh_enabled = (ret_code == NRF_SUCCESS);
CRITICAL_REGION_EXIT();

According to the highlighting by SES, ANT_LICENSE_KEY is not defined, so it's resetting semoewhere in sd_softdevice_enable, but apparently without getting to app_error_fault_handler. I have no visibility into the softdevice, so please wave your magic wand over it and tell me hwat I'm doing wrong.

RE: Failure in ble_stack_init during startup

SteveHx — Fri, 12 Jun 2026 15:13:39 GMT

Correction to the above: It's derailing in nry_sdh_enable_request, which is the first function called from ble_stack_init.