Failure in ble_stack_init during startup

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?

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

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

  • 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;
        ...

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

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

Related