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?

[SteveHx]

Digging further back into my journal, APP_ERROR_CHECK was tripped when nrf_sdh_ble_enable return an error code of 8. Leading up to this, nrf_sdh_enable_request had returned 8 also, but nrf_sdh_ble_default_cfg_set had returned 0.

In attempting to troubleshoot this, I had added a call no nrf_sdh_disable_request at the very beginning of ble_stack_init, ignoring any returned error code from that. Removing that line doesn't change anythng.

[SteveHx]

An additional clue: When I erase my external nonvolatile memory (via a command on the BLE link), I finish by sending an acknowledgement message via BLE and then call NVIC_SystemReset(), and the system restarts perfectly. The message never shows up on the BLE link, presumably because the system gets reset before it goes out. The message acknowledging the beginning of the erase process always shows up, and the erase is indeed successful.

[Vidar Berg]

SteveHx said:

If run with Build and Debug, it runs fine.

What I wanted to confirm is whether it continues to run fine on subsequent reboots as well.

SteveHx said:

thing I record is RESETREAS after each startup. It appears to have a value of 0x00000004 on a successful startup, and 0

Does your FW clear the register after reading it? Is important to remember that this is a retained register. If it is zero it indicates a POR or BOR reset. Another question is if you can trust the recorded value if the device is going in a boot loop. I would instead suggest that you read out the RESETREAS register with your debugger.

SteveHx said:

DEBUG is apparently defined when doing Build and Debug, so my logging was tripped even though the code neve

Whether DEBUG is defined or not depends on your build configuration. We include it in our debug build configurations in our SDK examples:

SteveHx said:

id - 00004001, pc - 00000000, info - 2000FF6C

You can get it to print out the file name, line number and error value by retrieving the error from the info pointer as done in the default handler here: 

SteveHx said:

finish by sending an acknowledgement message via BLE and then call NVIC_SystemReset(), and the system restarts perfectly.

Does it continue to work after this? E.g., after a power cycle.

[SteveHx]

ResetReason = NRF_POWER -> RESETREAS;
NRF_POWER -> RESETREAS = ResetReason;

The debugger works poorly or not at all beyond being a program loader when using the softdevice. I added the code you suggested above, and never got it to output (never reached). I added some probes to see where we're going off the rails, and now we're resetting somewhere inside ble_stack_init(). I'll add some more probes inside there.

How late are you working today? Pretty sure you're in a time zone several hours ahead of me.

[SteveHx]

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