Occasional reset after TX, VDD plots inside

RE: Occasional reset after TX, VDD plots inside

kobyatom — Thu, 05 Jan 2023 10:52:12 GMT

thank you very much for this much needed FW workaround.

RE: Occasional reset after TX, VDD plots inside

kobyatom — Thu, 05 Jan 2023 10:51:44 GMT

Thank you very much !!! great catch.

RE: Occasional reset after TX, VDD plots inside

hmolesworth — Fri, 25 Sep 2020 21:11:18 GMT

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.

RE: Occasional reset after TX, VDD plots inside

ULPDev — Fri, 25 Sep 2020 20:27:53 GMT

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.

RE: Occasional reset after TX, VDD plots inside

Kenneth — Tue, 15 Sep 2020 09:03:37 GMT

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

RE: Occasional reset after TX, VDD plots inside

ULPDev — Sat, 05 Sep 2020 20:47:01 GMT

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.

RE: Occasional reset after TX, VDD plots inside

Andreas — Tue, 11 Aug 2020 06:23:33 GMT

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

RE: Occasional reset after TX, VDD plots inside

ULPDev — Fri, 07 Aug 2020 11:33:36 GMT

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.

RE: Occasional reset after TX, VDD plots inside

Andreas — Fri, 07 Aug 2020 11:11:46 GMT

Hi,

The dip at C is likely the battery not able to supply enough current, reducing the voltage. Where is the voltage measured though, at the pin of the module or further away? What do you get if you readout the RESETREAS register?

Best regards,

Andreas