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]

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).

[SteveHx]

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().

[Vidar Berg]

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.

[SteveHx]

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. ?!?!?

[Vidar Berg]

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

[SteveHx]

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.