Programming Propeller Memory With Prop Powered Down
JRoark
Posts: 1,215
in Propeller 1
I have an application that will require any code changes to be downloaded while the Propeller is completely powered down. This means an external programmer (Propeller-based! Lol) will be asserting control of the I2C bus and providing local power just to the EEPROM briefly during the programming process.
Will the Propeller tolerate this scenario gracefully, or is it going to get grumpy, drag-down the bus, or be damaged?
Will the Propeller tolerate this scenario gracefully, or is it going to get grumpy, drag-down the bus, or be damaged?
Comments
-Phil
There are parasitic clamp diodes on all the pins to Vcc/Gnd.
Can you instead arrange to just hold the Prop in reset during the program phase ? (Not sure what Prop during-RST current is ? data shows low current for 50ms right after reset release)
Addit: Found the thread where during-reset is mentioned, varies with BOD enabled, or not.
http://forums.parallax.com/discussion/129731/prop-limbo-how-low-power-voltage-can-it-go/p1
Data says this
BOEn I Brown Out Enable (active low). Must be connected to either VDD or VSS. If low, RESn becomes a weak output (delivering VDD through 5 kΩ) for monitoring purposes but can still be driven low to cause reset.
If high, RESn is CMOS input with Schmitt Trigger.
RESn I/O Reset (active low). When low, resets the Propeller chip: all cogs disabled and I/O pins floating. Propeller restarts 50 ms after RESn transitions from low to high.
Looks like most Icc with BOD enabled, (RST externally active) is due to that 5k weak output pullup on the reset pin.
PhiPi: I’ll be using a Schottky diode to keep the EEPROM power from backfeeding the Prop. But I honestly had not even considered the possibility of the data pins on the Prop wrapping around and providing “phantom” power to the Prop. Thats a really good point. So it looks like I’ll need to spend some time running it down (or brute-forcing it with a couple more diodes. Ick...)
Thank you both for the quick replies!
As to holding the Prop in RESET or a BOE condition during an update, the customer wont swing with this. He is completely catatonic about having everything except the EEPROM “dead” during an upgrade. Any further discussion about this with him is unlikely to be helpful. So... diodes!
-Phil
Surely he knows that RESET is dead, aka completely catatonic. The prop is not doing anything at all, when it is in RESET.
If you really do need tolerant separation, N MOSFETs can give that, with pullup resistors.
-Phil
When Prop is in reset the supply voltage not lower, it is still 3v3, so there are no parasitic current effects.
-Phil
Enjoy!
Mike
When the Prop is held in reset it is effectively "unpowered" with all I/O floating but with the silicon able to tolerate 3.3V being placed on the I/O as in the case of the I2C lines.
So using the dual regulation scheme with one powering the Prop and EEPROM and the other everything else but which also holds the Prop in reset is the way to go I would think. Otherwise you will have to isolate the I2C lines from the Prop for sure and you could use an analog mux chip or even an I2C isolator but having a dedicated regulator for the CPU and EEPROM separate from all other I/O is a good design choice since during normal operation your controller is not affected by noise on the I/O side. Indeed if the I/O side overloads its regulator then the Prop would go into safe "shutdown"
Physically disconnecting the eeprom SDA and SCL lines from the prop is probably the simplest route, but I would suggest using a small pin header so you can remove the prop to eeprom jumpers and connect your programmer header directly to the eeprom pins. If you also need to provide power to the eeprom then a total of 7 or 8 pins would be needed.
Attempting to boot both chips at the same time from the same EEPROM always results in the new chip booting. I suspect this is because it has no reset circuit and "wins" the boot race for access to the common EEPROM.
There is no evidence of any sort that the new chip is parasitically powered by the voltage on 28 and 29 as the primary chip is programmed. No voltage appears on any of the other pins.
So the experimental result is: Yes, you can program a powered-up EEPROM whose SCL and SDA lines are connected to pins 28 and 29 of an unpowered P8X32A. The Propeller will not affect the programming operation or be energized by it in any detectable way. As long as the programmer (in this case the primary prop) tri-states its programming lines, when the unpowered Prop is powered it can read the EEPROM and boot normally.
Even if it did manage to magically power up I don't think it would do anything; when both chips are powered only one boots and the other doesn't interfere with it. Since the other can't load a program it doesn't do anything even though it is powered up.
That would be interesting, because my meter shows clamp diodes on all P1 pins (Diode range gives 578mV on all pins, and 566mV on i2c, I think due to EEPROM AND P1 diodes in parallel )
Yes, it may work, there is a band where i2c can go high enough to be seen as logic 1, but not so high as to drive the isolated P1 above BOR via the parasitic diode.
If there is another load on the 'disconnected' 3v3, in the OP's system, things get harder to predict.
With the scope there is definitely some weird stuff going on. With just the unpowered prop hooked up, no bypass cap or load, Vcc does show 3v3 but about every 55 milliseconds there is a sharp dip to below 2V. This appears to be coming through the pullup on SDA. The chip is otherwise dead, presumably because it is trying to go through its boot sequence and getting reset at some point when it draws too much power and Vcc drops.
While programming an EEPROM Vcc goes to 3v3 continuously, but the unpowered chip doesn't interfere with the programming process probably because it is still the "loser" of the race to start with the powered Prop. So far so good.
But put a 10 uF cap across Vcc and GND of the unpowered chip, and the 55 msec down pulses go away. Now when you try to program the powered prop, Vcc drops to about 3V then recovers over 100 msec or so and the programming operation FAILS. Presumably this is because the unpowered Prop is alive and ready, and "wins" the race for the EEPROM because it's been alive while the powered Prop was being reset. Then the bypass cap discharges enough that the unpowered Prop resets.
But then I put a 10K load across Vcc and GND along with the bypass cap, and Vcc drops to about 1.3 volts. It rises to 3v3 during the programming operation but doesn't interfere with the program process, presumably because it isn't alive on only 1.3v and again it "loses" the race to the EEPROM.
Finally I removed the PPDB's Prop so I could power the EEPROM with only the unpowered Prop connected. (Remember thru-hole socketed boards?) Even though Vcc rises to 3v3, (bypassed and no other load) there is no evidence of any attempt to read the EEPROM.
So long story short the OP's scheme might work, depending on other loading conditions and the timing of the programming operation, but it's not at all a sure thing. Mea culpa.
There have been so many good responses here that I'm frankly floored. I'm especially appreciative of LocalRoger's efforts to tinker with the Prop-on-Prop booting idea. I'm going to spend the weekend playing with this a bit more and see where it gets me. Even if it does not reliably cut it, it still fascinates me.
Again... many thanks to all for the input. I'll report back what I find as well so the next guy who walks this path can see what we did.
1. Breadboard a circuit to represent the Prop with all its peripherals that you can keep unpowered except for the EEPROM. A working board could be used for this if you just remove the built-in EEPROM and use a few jumpers to go to your programming circuit. Breadboard another EEPROM which can be powered separately but connected to the Prop's ground and EE programming pins. Make sure that with the Prop unpowered and the EEPROM powered, the Prop's Vcc is no more than 2 volts. If there is much circuitry at all on the Prop's PS in addition to the Prop itself, this is likely to be the case, and you're OK to...
2. Try programming the EEPROM. Check two things here; what happens to the unpowered Vcc? If it stays below 2V you're golden. In my case it snapped to 3v3. If it stays in viable range for the unpowered Prop to wake up, did the programming operation succeed? In this latter case you should do many trials to make sure there isn't a race condition you sometimes lose. If you can program the EE 50 times I'd consider it worth fabbing a more accurate test article for the final assembly.
Of course, as noted above a solid and totally definite solution is to put a DPDT switch on the EEPROM's programming pins so only one circuit can see them at a time. Problem solved, but only if you have local physical access to flip the switch. A mechanical DPDT relay would also do the trick, and there's no wondering about whether it would work.
It was an interesting problem and I learned something, thanks for the challenge.
My thinking is just use resistors and the diode and as long as your programmer system drove the clock high rather than relying upon pull-ups and had a relatively strong pull-up on the data then it should work without any adverse affects. A switch or relay is not only clunky but introduces a likely point of failure in normal operation. Remember, external programming is a convenience that will only be required maybe once or twice in normal operation but 24/7 the system needs to operate.
EDIT: Heck, if it's that infrequent you could use 3 dip switches for that matter with one for the EEPROM power. Push all three in one go with a flat blade screw-driver.
I have found that, just as advertised, the Prop is very well behaved if you force-and-hold a RESET condition while programming the EEPROM. I cant actually use this trick for the immediate design but it was fun to play with it against future need. It’ll come in handy down the road.
The Prop does NOT like to be “backfed”. No matter how I slice it, there does not appear to be a way to keep the Prop from back-conducting and doing.... something. I’m here to tell you that little critter sure feels like its trying to boot when I program the EEPROM. It appears to be doing a “surge and reset” for lack of a better term. Watching the power supply numbers it is clear there is mischief afoot in its silicon head!
I’m going to keep noodling with it, but it does appear the only customer-acceptable solution will involve a physical switch. To my eyes this is a rather ugly kludge, but The Customer has spoken. So I’ll likely use a pair of Dow connectors and a header block: insert one for programming (jumps-out the EEPROM for programming) and insert the other one to jump-in the EEPROM for “normal” use. Not real elegant, but....
I’m going to be owing several of you guys a beer. The assistance and discussion here has been invaluable to me. Thank you!
Simple, easy, quick.
( I say this because I am constantly amused by the complicated methods that some will try and yet ignore simple solutions because, well, because they are simple).
Mike