Power brown out locked up Prop

T Chap

I came into my office today, my Mac was off and strangely took a few attempts to get it back on. My pc was off. I just now many hours later tested out my Prop gadget as I always do a few times a day, and it didn't respond at all. I reset the power to the board and everything worked. I have no idea what really happened or how long it lasted, but the Prop just hung up. The reason I say it was the Prop hung up is that more than one sensor didn't cause a response. Granted, they were both on same I2C lines. It is programmed to handle situations where there is a complete power off/on, but it didn't handle whatever happened, and for this gadget that isn't a good thing.

Any suggestions on a circuit or other method short of an aux AC standby to prevent such a strange locking result?

Mike Green

Perhaps there was some kind of power surge or power outage associated with noise on the power line. Obviously, the Prop was not well programmed to handle a complete power off/on cycle. Usually to make this kind of thing work, there has to be enough power storage locally to keep the Propeller running until it can complete its power off processing and it has to reliably sense the loss of power. In addition, if power comes on, the Propeller has to be kept in reset until the power has been restored long enough for the power on and power off mechanism to function reliably again should the power fail immediately.

BradC

Sounds like you need a hardware watchdog.

The cheapest way I've done this in the past was a 555 timer wired as an astable oscillator with about a 10 second period. Use a pin from the prop to reset the timer periodically and hook the output of the timer to the reset line. That roughly gives you 10 seconds after the first reset to start resetting the timer. If the prop stops pinging the pin the timer will reset the chip.

There are a gazillion dedicated tiny watchdog chips out there that will do the task far more elegantly however.

Do you have the brownout detect enabled?
Is it possible that the prop was running ok but one of your I2C peripherals had done something funky to lock up the bus? Does your I2C code auto recover from bus-farts, or does it sit waiting for ever while it recovers?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

T Chap

BOEn is fixed at Vss.

Thanks for the ideas. I have never experienced anything like this with I2C or the Prop. Unfortunately I didn't think it through before I rebooted, else I should have looked for activity to see if the Prop was still trying to read the sensors. Even if the Prop was fine and the I2C sensors were crapped out, I don't have a method to hard reboot the power lines via the Prop if that were the case.

I think a future solution will include a regulator with enable input.

Post Edited (Todd Chapman) : 11/17/2009 6:37:38 AM GMT

BradC

Todd Chapman said...
BOEn is fixed at Vss.

Thanks for the ideas. I have never experienced anything like this with I2C or the Prop. Unfortunately I didn't think it through before I rebooted, else I should have looked for activity to see if the Prop was still trying to read the sensors. Even if the Prop was fine and the I2C sensors were crapped out, I don't have a method to hard reboot the power lines via the Prop if that were the case.

I'm not sure it's that sinister. I'd be looking at the I2C driver a bit closer to see if there is anywhere it might get jammed if one of the sensors does something funky. Yes, the sensor itself might have wedged the bus, but I'd be looking a bit closer at error recovery and timeouts in the driver. Maybe intermittently do nasty things to the bus (you know, screwdrivers* to VSS/VDD and other nasties) to see that it recovers properly each time.

* of course anything I suggest is likely to end up with damaged hardware, but then you'll know your software is OK [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

T Chap

I made a mistake. One of the sensors I checked was on a dedicated serial i/o, the other sensors I2C, both on separate cogs.

I have done tons of screwdriver type tests and have never once locked one of these up. I have hot swapped entire I2C boards (power and data) literally hundreds of times while the Prop was trying to talk to them, never seen a problem.

The MAC took a number of attempts to get back up and running, a new iMac I mean if Apple can't handle a surge or brown out properly then how am I supposed to! [noparse]:)[/noparse]

T Chap

I have a theory.

I think what happened is that the Prop reset fine, and the Vinculum hung up. The Init probably got stuck waiting on E sync to the Vinculum since I never allow an escape route if there is no sync, never needed a way out since it never has failed. I need to connect a Prop pin to the Vinculum reset pin on the next rev.