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]

I'm running Windows 10, as I have from the very first time I used Nordic and the Segger tools, which have always worked fine. Highly unlikely that anything is writing to that virtual drive; I have scanned for malware within the past few days. Also, I did a complete dump of the flash both after programming via build&run, and after programming via drag&drop. A file compare utility declared the two files to be identical.

[SteveHx]

Aha, a glimmer of daylight....

It appears that I need to investigate my power supply, even though it's identical to that on the previous rev. Please confirm that the following waveform would be causing resets. Steady at 1.8V, rising to 3.35V over the course of 9.5 mSec, immediately falling to 2.2V over 5.2 mSec, then more steeply to the baseline steady 1.8V over 600 µSec.Cycle repeats every 37.8 mSec, which seems reasonable for the reset loop I'm seeing.

I don't know how the supply can be doing that, but clearly it is. The previous rev does not show this behavior, despite being by design identical. Something must be different in the build, that is causing a power supply disruption as the softdevice starts up. But why would it behave differently when programmed via drag&drop?

[Vidar Berg]

This is great progress. It seems safe to assume that POR is the likely culprit now. Here is from the nRF52832 Product Specification:

(Ref. https://docs.nordicsemi.com/r/bundle/ps_nrf52832/page/power.html).

I don't have a good explanation for why you're not experiencing sudden PORs in debug interface mode or when using drag&drop programming. Generally on powerup, there will be more inrush current, and the regulator may also need some time to settle. Perhaps it becomes more apparent what is happening when you probe VDD in these different scenarios and across different boards.

The current draw from the chip could also have something to do with it. The current will never drop down in the uA range when the chip is in debug interface mode. So if the drag&drop method is not existing debug mode after programming, then that could potentially explain why it is behaving the same as when you start a debug session in Segger embedded studio.

(https://docs.nordicsemi.com/r/bundle/ps_nrf52832/page/dif.html?section=debuginterfacemode)

[SteveHx]

I know this is now wandering afield from the nRF52832, but I'm quite stumped. There are no logic lines back to the power supply, and the supply is rated a couple of orders of magnitude more current than used by the nRF52832 and the rest of the system. When programmed via drag&drop, the supply starts with the output voltage is at 1.8V, rises to 2.4V in about 9 mSec, steady at 2.4V for 30 mSec, drops abruptly to 1.8V in about 1.2 mSec, and repeats. This is apparently too slow and too small to trip the reset circuit. Feedback solidly tracks the output action, so I can't see why the TPS62050 switches on steadily when the output is too high. Circuit matches the example circuit in the TPS62050 datasheet, and layout is very tight. And it worked perfectly in the prior rev. Load is in the realm of 10 mA in both cases. Any ideas welcome!

[SteveHx]

My design has the same caps around the nRF52832 as the devkit does, plus 22µF bulk capacitance at the output of the voltage regulator. Could the nRF52832 require more capacitance? Does the code in the softdevice supporting sd_softdevice_enable() make any major transient demands on Vcc? I'm hunting for something that could drive the TPS62050 downswitcher to go into full conduction mode, driving the supply voltage up to almost double. Also, why should the behavior be any different when using drag&drop programming? Even then it's a bit bizarre, but only jumps up to about 2.2V, so not enough to trip the reset. The pattern is very different too, staying mostly steady at 2.2V most of the time, with short drops to the design target of 1.8V.