Failure in ble_stack_init during startup

[SteveHx]

We are trying to bring up a new run of an existing PCB design. No changes in the area of the processor, but a different assembly house. The first call inside ble_stack_init, a call to nrf_sdh_enable_request(), fails and returns an error code of 8. No reference anywhere gives a usable explanation.

Strangely, if started by "copying" the hex file onto the Jlink "drive" (the nRF52832 DevKit), it succeeds.

What should we be looking for?

[Vidar Berg]

Hello,

It seems like the issue might be with how the firmware is programmed since it appears to work when you use drag&drop programming. How are you programming the device when it fails? Is the same error also returned after a reset? Note that the "SoftDevice enable" function may return NRF_ERROR_INVALID_STATE (8) if the debugger forces execution to start from the application start address instead of address 0x0. This prevents the softdevice's reset handler from running on startup.

Best regards,

Vidar

[SteveHx]

I was starting it from SES (Segger) just as I have on dozens of previous nRF52832 projects, and indeed successfully on previous runs of this board. So there's something different in the hardware, and I'm asking where to look. What sort of "invalid state" is likely?

[SteveHx]

2026-06-19  9:01:12.66 d:\Download>nrfjprog --memrd 0x40000400
0x40000400: 00000000                              |....|

2026-06-19  9:03:16.55 d:\Download>nrfutil device read --address 0x40000400 --direct
682528135
0x40000400: 00000000                              |....|

So, this reports RESETREAS as all zero, just as my code did. I'm not sure what the second line does, but I think that's the startup value of the stack pointer.

Next?

[Vidar Berg]

Please confirm whether you changed your code so that it is no longer clearing the RESETREAS register. This step is essential for this test. The second line there is the serial number of the debugger and is not a valid memory address.

[SteveHx]

Yes, and I deleted all extraneous code prior to the BLE initialization. It still crashes in the same place and resets.

[SteveHx]

I find that the Beacon example (hex files) runs fine both from drag&drop and from power up. Thus I looked at the source code in main.c for that example, and tried to make my startup identical. It was a struggle, with unresolved references, but by including a bunch of extraneous (to our application) headers, and ble_lbs.c, I was able to get it to work - sort of.

The main additions were log_init(), leds_init(), and buttons_init(), none of which are relevant to our application. If I comment out the call to buttons_init(), it runs exactly as before - just fine from drag&drop, hangs in ble_stack_init() from power up. With the call to buttons_init() included, ble_stack_init() trips two errors. The calls to both nrf_sdh_enable_request() and nrf_sdh_ble_enable() return an error code of 8. I have bypassed the APP_ERROR_CHECK calls because they do nothing useful for me, so it's not surprising that the second call above would return the same error code as the first.

So the two bottom line questions:

1) What is different (and why) in the reset process from drag&drop vs. powerup?

2) What is different between the E1 and E0 revs of the nRF52832QFAA chips?

[SteveHx]

Further research: The vector table at 0x00000000 looks like this:

20000400 00000A81 00000715 00000A61

How can the reset start address not be a multiple of 4? If I understand correctly, all instruction words are dword aligned.

Clearly the drag&drop downloader sets up something that the normal reset code does not, and whatever that is, is cleared by a power cycle, only to be reset by another drag&drop, or by starting the debugger. And it's something the E1 version hard reset sets differently than the E0 version.

Also, studying the .map file leaves me even more confused. There appears to be a vector table at 0x0000000000026200, but the entries are only 2 bytes each. Good trick, if those are 32-bit addresses. This appears to not be the vector table that goes at 0x00000000, because it has things like NMI_Handler, HardFault_Handler, etc. Our code appears to load just above this table, because I see names of my routines here. They are word-aligned, refuting my assertion above that instructions are 32 bits; that makes more sense. Still, that "reset" address of A81 does not make sense.

I also see NVIC_SystemReset at 0x0000000000029208, and the system boots correctly via that routine. However, whatever was set up in drag&drop has already been done and remains in effect; again, the reset code is missing something important, but what? Also interesting is that there are multiple instances of NVIC_SystemReset, apparently because that's actually a macro, parsed in different files. The one that I've been calling from my code (after an erase operation on NV memory) lives at 0x000000000002ADB4.

Is there any other useful information to be gleaned from the .map file? How about answers to question 1 & 2 in my previous post?