Using Same Supervisor for POR and DCDC PSwitch

[alan-p]

We are having problems with brown out conditions with the RT1064. When power voltage drops, and returns to normal, our MCU is no longer powered. Full power cycle is needed to get our device back into a good state.

We have a supervisor for the 3.3V rail, which asserts POR if the voltage drops too low. In certain brown out conditions, we see POR trigger; however, 1.1VSOC goes low and does not come back. Doing some research, we learned that DCDC will disable output if there is an under voltage condition, and that DCDC_PSWITCH must be driven low for 1ms to reset the DCDC.
Our plan is to add a trace from the supervisor RESET pin to PSWITCH, such that in a brownout  our supervisor will assert both POR and PSWITCH. Bench testing shows that this works.

Is there any reason this design is a bad idea? We noticed that the EVK uses two supervisors, one controls the whole DCDC_3V3 rail (which feeds PSWITCH), and another one resets POR.
The only advantage I can see for having two supervisors is to make sure the MCU gets 1.1V before asserting POR. If this is necessary/desired, could we achieve the same thing with an RC delay?

For units we have already deployed to the field, anyone know if there is a way to disable DCDC's under voltage protection in firmware (e.g. a register setting)? I tried changing various DCDC register settings, but nothing stopped DCDC output from disabling during brownout.

[mjbcswitzerland]

Hi

I made a typo with the 10ms. It is 1ms, and not for the POR (but to ensure the DC/DC converter starts correctly). I think I use 10ms in the KL03 solution and incorrectly took it from there.
NXP's design guide " MIMXRT105060HDUG"

was used for the development and specifically to solve the HW errata of Rev. A version of the 105x, which has additional requirements.

It is true that the POR is controlled internally but I prefer to use the external method to be absolutely sure, plus have the ability to command an "external" SW reset and not just power cycle (SW reset and WDOG resets).

The KL03 costs about $0.50 and, when also used as an accurate very low power RTC in the design it is in fact cheaper than using a reset controller and RTC (and solves development complications which otherwise tend to use a DIP switch). However the main advantage is in helping ensure mission critical designs which can reliably recover from all possible problems.

Regards

Mark

[alan-p]

High Mark,

Thanks for the response. I think adding a separate MCU as a hardware watchdog would add more cost/complexity than we want for our product. User always has physical access to our product. So, a weird outage that happens once in a million uses is not a big deal. Also, our flash writes are exceedingly uncommon. We are banking on the primary cause as being brown outs.

I did some more reading. According to the reference manual, the use of external POR_B is optional. The MCU already has an internal POR_B that asserts until 1 ms after 1.1V is stable. The RM says external POR_B can be held high or left disconnected and the internal POR_B will take over.
Our plan is to leave external POR_B disconnected and connect our supervisor's reset pin to DCDC_PSWITCH. Testing has showed that this configuration powers up reliably and handles brown outs.

I couldn't find anything in the datasheet or RM that said a 10ms delay was required between DCDC_PSWITCH and POR_B. Perhaps you are thinking of another chip. I assume that the 1ms used in the internal POR_B is sufficient, or the chip designers would have used a longer delay.

[mjbcswitzerland]

Hi

There are various ways that the i.MX RT can remain in a non-usable state and can only be recovered by a power cycle (which is why the EVK in fact has a power cycling button).

As well as HW related ones such as you have, resets taking place when the internal flash is busy (writes/erasures) will also not allow it to restart (it will switch to ISP mode instead as the flash can't be booted from). Certain unrecoverable SW failures can also cause similar issues.

My solution has been to use the following technique, which is a reliable, low space and low cost solution that adds various other features/advantages (it can also be used as an accurate low power RTC or backup storage with much lower backup power consumption as the i.MX RT's or commanded to power down the i.MX RT circuit for a pre-defined period of time:
https://www.utasker.com/docs/iMX/uTasker_iMX_WDOG.pdf

Having large quantities of i.MX RT based products in the field I never dared to deliver any without this support. I also stock large quantities of the miniature KL03 (was branded as world's smallest ARM processor) to ensure this solution for anyone who needs them.

As long as the 1ms delay between the DCDC_SWITCH and POR is respected the same control source from an external supervisor should be OK to recover from voltage related issues.

Regards

Mark