Occasional reset after TX, VDD plots inside

[ULPDev]

I'm working on a project that uses the Fanstel BC840m module. The project uses a custom PCB design, and everything was going smoothly until... I enabled DCDC1, stopped building in DEBUG, and switched to battery.

Issue

When I enable use of DCDC1 I experience frequent (~5% probability) resets after BLE advertisements. 

Hardware

• Custom PCB
  • XTAL populated and configured
• Fanstel BC840m (52840 based)
  • Docs state the module has components to enable DCDC1
• Coin-cell battery (CR2032)

Software

• SDK v16
• S140 v7.0.1

Observations

• Reset occurs immediately after completion of BLE advertisements
  
  • Verified by oscilloscope on VDD
• Reset occurs, with less frequency, when powered by Nordic PPK and voltage reduced to ~2.5-2.5V
• I have many custom PCB units. Reset frequency varies by unit. Some are very bad (seconds), some are better (hours)

Troubleshooting steps

• First instinct is voltage drop problem, so I added additional capacitance to the host PCB, and moved that closer to the Fanstel module connections. This might have made a slight improvement, but not much if any.
• I've attached an oscilloscope to VDD to watch for drops. 2 snaps are attached.
• I've read nearly every post here that mentions DCDC. I've learned a lot, and I know that coin-cell batteries as a power supply are difficult... But nothing I've seen seems to explain this.

Screenshots

Here are two screenshots watching VDD during a BLE advertisement TX cycle. Note: I have masked off 2 advertising channels, so there is only 1 BLE transmission per cycle. The first screenshot here is of a "clean" TX where the unit did not reset. I labeled several key events with letters A, B, C, D. Can someone tell me what is causing D? D is exactly where the reset occurs, you can compare the two screenshots to see. Sorry they're different time-scales so they don't line up perfectly.

A - Some sort of soft wakeup, I'm guessing to get the CPU and radio ready for TX

B - DCDC power-up and charge

C - BLE TX

D - ? Why the dip? Is this where it's switching back to LDO? This is the point at which resets occur. See next picture. 

/resized-image/__size/320x240/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-07a8564767104549a73a3cf71d0992d9/Screenshot-from-2020_2D00_08_2D00_06-08_2D00_17_2D00_15.png

/resized-image/__size/320x240/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-07a8564767104549a73a3cf71d0992d9/Screenshot-from-2020_2D00_08_2D00_06-08_2D00_17_2D00_41.png

FWIW -- I also have a custom PCB that uses the Fanstel BT840 module (still 52840 based). Under the exact same software configuration (and nearly equivalent schematic) I have not experienced a single reset. 

So does anyone have ideas? What is happening at D? Is it something I can control to prevent the reset? Any ideas on what the underlying cause may be? I would love to find a software work-around, even if there is some penalty, but I'd also like to identify the true cause and resolve that for the next HW spin.

[ULPDev]

Hi,

Thanks for the response.

RESETREAS is 0. (Which I'm aware would indicate BOR)

To be clear, yes C has a big dip, that's not very surprising. It's the "relatively" small dip at D that is interesting. D is the point where the reset occurs.

The voltage is measured as close to the chip as I can get. ~1.5mm away.

Thanks.

[Andreas]

Hi,

 

OK, now I understand. Hard for me to say without knowing what is happening after D, but seeing as it has been reset I would expect some sort of start-up procedure, during which the CPU will be active. This will draw current, not as much as the radio but also you can see that it does not drop as steeply as C. Whether or not it uses LDO or DCDC depends on where you enable that in your code.

 

Best regards,

Andreas

[ULPDev]

I know it's been awhile since I updated. I have continued to troubleshoot. I found a workaround, but I don't like it as it doesn't really solve the problem, just masks it.

First off, I can reproduce the issue with the beacon sample application from the SDK on my custom board. All I did to that application was enable DCDC, and ramp up advertisement frequency (to trigger the reset with less waiting). The "dip" at D above exists with this application too. 

To partially answer my question from above about what D is I did find these two documents:

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_processor_avail_interrupt_latency/ble_broadcaster_performance.html

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_power_profiles/advertising_event.html

I did find that inhibiting "idle sleep" stopped all resets. I also found that keeping the HFClock on (with nrf_drv_clock_hfclk_request(NULL);) stopped all resets. But neither of those are acceptable solutions or workarounds as they have substantial power penalties.

Disabling idle sleep and locking HFClock appear to keep DCDC on, which eliminates those transitions and resolved the resets.

It sure looks like there is some weird timing or interrupt issue that can arise when the SoC switches from DCDC to Ldo. Perhaps this doesn't manifest 99% of the time but if the hardware margins are just right (and by that I mean on the wrong side of right) this problem appears.

Could it be that the SoC is switching from DCDC to LDO before LDO has sufficiently stabilized, which causes BOR? This may only happen on battery in certain hardware designs that have trouble providing surge current. 

Disabling idle sleep and locking HFClock appear to keep DCDC on, which eliminates those transitions and resolved the resets.

Workaround that surprisingly works:

I enabled radio notifications, when I get the radio active notification I enable DCDC. When I get the inactive notification I disable DCDC. Somehow, this resolves the issue and there is no reset by the transition back to LDO. I have observed the VDD traces with the scope and I can confirm that DCDC is actually getting enabled/disabled by this. I understand that the application is never really in control since per the documentation if DCDC is enabled then the SoC will choose which regulator to use based upon current load. This workaround has brought my application's current draw down to very close to the draw I had measured with DCDC enabled all the time. So this is an "acceptable" work around. But it is still a workaround with an unexplained "why".

I believe there is some very low probability timing issue/glitch that comes into play in the LDO->DCDC transition that is exacerbated or only manifested in certain hardware configurations. It would be easy to blame this on the custom hardware but the fact that I can workaround it as above would seem to indicate there's more to it then that.

Is there any NRF Engineer that can comment on this from the HW perspective? Are there any undocumented engineering values that could be changed to adjust the way LDO->DCDC transitions are scheduled/performed? I would love to understand the "why" so that I can proceed with confidence...

Edit

This hasn't completely resolved the resets. They are very infrequent, going 12 hours or more without reset.

[Kenneth]

Hi,

Andreas is currently out of office.

You observation is odd, I can't think I have seen something like this before. Typically dcdc is enabled at start of main(), and the hardware will then startup dcdc as required automatically without any more user "intervention".

Can you share the schematic for the fanstel module and the additional components you have placed around the module?

It's difficult to see the details of you traces, for instance the voltage level and timing is not possible to read on the traces.

Are you able to provide the chip markings printed on the nRF52840 ic of the fanstel module?

Kenneth

[ULPDev]

I have resolved the issue. It was on the hardware side. I removed the BC840M module's EMI shield and noted that the module does not contain all of the recommended capacitors on VDD. I created a new hardware revision to add additional capacitance right next to the BC840M. I have not observed an unexpected reset with this design.

[hmolesworth]

There is a known issue with slow and fast rise times on Vdd which can lead to a reset; this can be caused by a dip and recovery in voltage on the nRF52832 when insufficient Vdd capacitance is used on a coin cell (A step increase in supply voltage of 300 mV or more, with rise time of 300 ms or less, within the valid supply range, may result in a system reset) though is not listed on the nRF52840 product spec but a max is specified.

nRF52840:

tR_VDD Supply rise time (0 V to 1.7 V)  max 60 ms
tR_VDDH Supply rise time (0 V to 3.7 V) max 100 ms
TA Operating temperature -40 25 85 °C
Table 152: Recommended operating conditions
Important: The on-chip power-on reset circuitry may not function properly for rise times longer than the specified maximum.