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?

[Vidar Berg]

The invalid state is returned either because the softdevice has already been enabled, or because the softdevice's reset handler was skipped during the boot sequence. It is a known issue when using Segger that selecting Build & Run starts execution directly from the application, effectively bypassing the softdevice.

Similar case: https://devzone.nordicsemi.com/f/nordic-q-a/118688/nrf_error_invalid_state-softdevice-already-running 

[SteveHx]

I had anticipated that it might already have been initialized, so added a preceding call to nrf_sdh_disable_request(), but that had no effect.

What is the preferred approach when using Segger's Build&Run?

[Vidar Berg]

Build&Run does not work because it ignores the debugger settings and starts execution directly from the app skipping softdevice (and bootloader if present). Please try Build&Debug instead and check if you still get the invalid state error. 

[SteveHx]

That's quite strange. Build&Run (F5) has always worked in the past, and still works fine on the previous round of boards. It's only on the newest batch of boards that it fails, and the connections to the processor are electrically and physically identical. So I speculate there's some kind of fabrication problem. What should I be looking for?

[Vidar Berg]

The problem I have tried to describe where the debugger interferes with the boot sequence does not have anything to do with the HW, and there must be some other explanation for why you have not noticed this before with the other batches or revisions of your boards. The device will boot correctly after a system reset, so if the error handler calls NVIC_SystemReset(), it may mask the issue.

[Turbo J]

You need to flash prerequisites (like SoftDevice and Bootloader) only once before Build&Run starts working.

Edit: Disregard, I confused that with different tooling from another IDE. Below part could still mess things up though - but only outside IDE when running from POR.

Note that some module vendors may ship parts with pre flashed firmware - you also want to include a complete flash erase in the first flash step.

[Vidar Berg]

Build&Run will load the additional hex files specified in the project the same way as Build&Debug, so it's not that the softdevice isn't loaded. As mentioned in my previous replies, the problem is that Build&Run starts execution directly from the app's reset handler, which means the SoftDevice never gets initialized, hence the invalid state error. 

[SteveHx]

Getting back to this problem now after a few very busy days on family issues. In a nutshell: If I load the firmware via drag-and-drop to the "drive" representing the nRF52832 DevKit I'm using as a programmer, it runs fine. If I then cycle power, it hangs up in a loop that resets every time nrf_sdh_enable_request() is called. The latter behavior also happens if I program by pressing F5 in SES, and also if I program via the nRF Connect Programmer app. But none of the above problems occur on previous revs of the PCB, and there have been no changes to connectivity or even physical placement in the area of the processor. There is one additional I/O line in use as an input, with a 1K resistor connecting a signal to what was previously a thru-hole testpoint. However, the symptoms are the same even with that line disconnected. What should I be looking for?