Microcontroller, brownout bus reset
Microcontroller, brownout bus reset
(OP)
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
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





RE: Microcontroller, brownout bus reset
Dan - Owner

http://www.Hi-TecDesigns.com
RE: Microcontroller, brownout bus reset
RE: Microcontroller, brownout bus reset
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
RE: Microcontroller, brownout bus reset
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?
RE: Microcontroller, brownout bus reset
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
RE: Microcontroller, brownout bus reset
RE: Microcontroller, brownout bus reset
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 :(