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?

[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?

[Vidar Berg]

I hope things are better now. Regarding the SD enable issue, could you please start a debug session in SES by pressing F5 and confirm whether the program enters app_error_fault_handler()? If it does, could you also check where the error was raised? 

[SteveHx]

I did Build and Debug in SES. The program started at the beginning of main(). I then set a breakpoint at the first instruction in app_error_fault_handler(), and did Debug - Go. Program runs normally, no errors, breakpoint never hit.

Next?

[Vidar Berg]

Thanks for confirming. What happens if you power cycle the board after this, does it continue to work? If not, try adding the line below at the beginning of main(). This will prevent the chip from entering low power mode and will mimic being in debug interface mode. It would be helpful for troubleshooting to know if it has the same effect.

int main(void)
{
    NRF_POWER->TASKS_CONSTLAT = 1;
    ...

[SteveHx]

Interesting thought. There's no reason in my code that it should sleep within a few minutes of startup. I tried your suggestion; no change. If run with a power cycle, or with F5 from within SES, it still goes into a continuous reset loop. If run with Build and Debug, it runs fine. I have code at the beginning of main() that flashes an LED via direct NRF_GPIO access, so no calls to anything in the Nordic code. I also tried adding the line you suggested above both before and after that code; no change.

I have nonvolatile memory external to the nRF52832, wherein I can record a journal of actions. One thing I record is RESETREAS after each startup. It appears to have a value of 0x00000004 on a successful startup, and 0 when stuck in a loop. I will investigate that further.

Suggestions based on the above?

[SteveHx]

Here's something more interesting. I recently added logging to my journal for app_error_fault_handler(). I have a breakpoint at the first line of that function, which never hit. However, DEBUG is apparently defined when doing Build and Debug, so my logging was tripped even though the code never (?) went thru the breakpoint. It recorded the function parameters: id - 00004001, pc - 00000000, info - 2000FF6C. Interpretation?

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