Microcontroller, brownout bus reset

[CarbonWerkes]

Hello

I have an application that involves several microcontrollers and a number of peripherals on the same PCB. The MCUs leverage I2C to communicate with each other and with the peripherals (real time clocks, flash/EEprom, etc). Normally, one would use a CPU supervisor chip to just hold the MCU reset pins in 'reset' until the bus voltage stablized, but this can leave the peripherals in an unknown state- which is particularly bad with I2C if you are mid communication when a brownout happens.

Is there any reason why I should not just implement a p channel mosfet between the power supply and the bus, and have the CPU supervisor manage that? In this way, the entire bus would be powered down/up at the same time, emulating the normal power-up cycle. I cant see any problem with this, but there are few if any notes I can find on this approach.

Regards,
R

 

[MacGyverS2000]

You have two choices... either the bus structure can reset all attached chips (peripherals and CPUs alike), or you can make it the responsibility of the CPUs to reset the peripherals. Which one you choose will depend upon how you need your peripherals to react when they loose comm with the CPUs (if they're life-saving devices, they damn well better reset when the bus goes low rather than waiting for the CPU to get them out of some half-assed state).


Dan - Owner

http://www.Hi-TecDesigns.com

 

[sreid]

Some CPU supervisor IC's have an output that indicates the power is starting to go down. This is connected to a high priority interrupt (un maskable?) on the CPU and allows the CPU to do house keeping before the reset hits.

 

[itsmoked]

I'd probably use your FET switch scheme.

You can also use a supervisory chip to reset the processors and FET the IC2'd crap,(I hate IC2), as soon as the supply starts to brownout.

I generally do something like detect a dropping input voltage at the front of the power supply. This gives the system the filter cap time to do something. Something = orderly shutdown ending in a tight loop that can only be escaped from by a reboot.

You can have the tight loop remain until a supervisory chip sends a reset pulse, when the power has returned to normal.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[VEBill]

"...dropping voltage [->] tight loop..."

What happens if the dropping voltage goes back up to normal again, after triggering the tight loop, but before triggering the supervisor? Does the orderly shutdown include making sure that the supervisory chip has been triggered?

 

[itsmoked]

The supervisor can often cough up an interrupt then go thru its supply recovery assessment followed by issuing a reset pulse.

You can also have the processor's watchdog trip because it is no longer getting petted since a tight loop was entered.

Other possibilities are; some processors have comparison inputs, (like the PICs I generally use), that can do all these functions, or trigger them. They could also be used to to trigger a soft start after the voltage has returned.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[VEBill]

Excellent - sounds like 'belt and suspenders'.

 

[CarbonWerkes]

Hi all- thanks for the feedback on this.

This application is for non-critical data acquisition in a vehicle. So, the current plan is to have an external CPU supervisor monitor the power bus upstream, and have its reset pin driving a pchannel fet gate. When the supervisor sees a brownout, it flips off the mosfet, which kills the bus. Downstream, the MCUs (PICs in this instance) can leverage their internal brownout detection to complete an EEProm write, or close an I2C session, etc, since there are caps with decent storage. I think the CPU Supervisors generally have a 200ms restart lag once VDD> trip voltage, which would be more than enough to allow the Supervisor to re-trip if the supply is truly unstable. And, if you bypass the supervisor's VDD with a .1uF cap, the manufacturers claim you can prevent false triggers (i.e. noise on the power bus). I hope that is correct...

Keith, yea, I2C is the primary reason for all this hell. Unfortunately, with the 18F series PICs, you dont have an RS232 bus independent from an SPI bus (SDO/RX are multiplexed I believe). Since I need 232, I2c is the only option. The FJ chips have dual MSSPs, but I believe they are all 3V parts- and I need 5V ADCs for my sampling. Workarounds for these problems make things even more complicated