Programming Propeller Memory With Prop Powered Down

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?
«1

Comments

  • As long as you don't try to play host while the Prop is trying to boot it should be fine. The Prop's pins are all high impedance (input state, though nobody is home to read them) when it is unpowered.
  • You'll need to isolate the EEPROM Vdd from that of the Prop. Otherwise, when you power the EEPROM to program it, the Prop -- and anything else on the power bus -- will power up, too. And that will entail the Prop trying to use the I2C bus to access the EEPROM. But, without also isolating SDA and SCL, the Prop may still get parasitic power from them.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 13,343
    edited 2019-02-27 - 00:51:50
    JRoark wrote: »
    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?

    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.
  • LocalRoger: good to know! Thank you for that data point.

    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!
  • JMG: thats some good stuff. Those clamp diodes have the potential to play all sorts of mischief. Its looking more likely the “brute force diode option” will be needed.

    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! :)
  • Putting diodes in the SDA and SCL lines will prevent the Prop from downloading boot code when it's its turn to access EEPROM. (Think about which direction those diodes have to point.)

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 13,343
    JRoark wrote: »
    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.

    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 Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,254
    edited 2019-02-27 - 03:15:18
    Even with the Prop held in reset, there's still the problem of the pull-up on SDA trying to power the Prop and everything else on the board when SCL is low, which means that SDA will probably never go high enough due to the parasitic current.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • jmgjmg Posts: 13,343
    Even with the Prop held in reset, there's still the problem of the pull-up on SDA trying to power the Prop and everything else on the board when SCL is low, which means that SDA will probably never go high enough due to the parasitic current.
    ? I'm not following.
    When Prop is in reset the supply voltage not lower, it is still 3v3, so there are no parasitic current effects.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,254
    edited 2019-02-27 - 03:38:07
    But there will be with the OP's Schottky diode in place. That was my assumption, even though it's no longer necessary. (There may be other components on the board that the owner is more worried about being powered than the Propeller.)

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • well @Peter Jakacki is doing this since years with all his boards, having a second row next to the PropPlug serving /RST and IC2 and power., and YES if the P1 is hold in reset you can program the EEPROM with a second Prop.

    Enjoy!

    Mike

    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Peter JakackiPeter Jakacki Posts: 8,197
    edited 2019-02-27 - 08:03:53
    Yes, holding the Prop in reset is the way to go but maybe to compromise with the customer's request, you can get away with powering the Prop and the EEPROM from the same 3.3V supply that is diode isolated from the other regulators or whatever so that powers anything else. That way the "board" is powered off and the Prop is held in reset either by the external programmer or even better still by the main board supply. That is, if the main board power is coupled to the reset in some way then when it is off then the Prop will effectively be off even if it is powered externally. This overcomes any problems with phantom power which could also damage the Prop btw since there would be way too much current flowing through the I/O pin diodes to the Prop's Vdd. (It's about "relative voltages" and thereby current).

    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" :)

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Totally agree with Peter.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I think i'd use a toggle switch to physically disconnect the SDA and SCL lines from the prop and connect them to the programmer...
    Prop Info and Apps: http://www.rayslogic.com/
  • If your EEPROM is socketed (it should be) the changes can be made on another board and then the EEPROM reinserted in the target system.
    Infantryman's Axiom; Always cheat, always win.
  • kwinnkwinn Posts: 8,200
    edited 2019-02-28 - 05:03:14
    Rayman wrote: »
    I think i'd use a toggle switch to physically disconnect the SDA and SCL lines from the prop and connect them to the programmer...

    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.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • I decided to try this experimentally. I plugged a second Prop DIP40 into the breadboard area of a PPDB and wired it for power, with a removable jumper for the new prop's 3v3, and cross-wired to the PPDB EEPROM. Using the USB cable (which doesn't power the chip on a PPDB, I also need a 7.5V adapter) the presence of the second chip has no effect programming the primary chip. Once the primary chip boots, as long as its program clears DIRA[28..29] to make its EEPROM pins inputs, the second chip will boot from the native EEPROM and run the same program. As long as the new chip keeps its EEPROM lines inputs, I can use the primary chip to load and run a new program on the EEPROM without affecting the new chip which keeps merrily blinking its LED.

    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.
  • jmgjmg Posts: 13,343
    localroger wrote: »
    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.
    Did you check the 'disabled' chip's Vcc pin, and the HI levels on the i2c lines ?

  • Yes, Vcc stayed at zero. The only pins with detectable voltage on them were 28 and 29, which were of course busy programming the EEPROM. I don't have an oscilloscope but I can bring one to work tomorrow if you want to be sure nothing weird is going on.

    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.
  • jmgjmg Posts: 13,343
    localroger wrote: »
    .. I don't have an oscilloscope but I can bring one to work tomorrow if you want to be sure nothing weird is going on.

    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 )
    localroger wrote: »
    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.

    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.

  • I'll check it with the scope tomorrow. Given the behavior when both chips are powered up at the same time, I suspect the "loser" is seeing activity on the IIC pins and not even trying to load the EEPROM, since the chip that "wins" boots reliably. I don't have the "unpowered" chip bypassed when it is unpowered, which could also make a difference; I'll fix that. Since the IIC signals aren't continuous I think they would have a lot of trouble adding up to a continuous voltage high enough for the chip to function.
  • And... I was wrong, and I need to buy a new multimeter.

    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.
  • Apologies for being off-line for a bit. I caught the flu and wasn't going to budge from the bedroom for nuthin'. :)

    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.
  • Hi JRoark, hope you're feeling better. My takeaway if you want to try your original scheme would be this:

    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.
  • Peter JakackiPeter Jakacki Posts: 8,197
    edited 2019-03-02 - 02:39:28
    The problem with any test scheme involving an unpowered Prop chip is that it ignores the current that can flow through the silicon substrate diodes and into other circuitry that will draw current, even if the Prop doesn't due to being in brown-out reset. That current can permanently damage the Prop chip. Of course in a test environment without any other loading it will appear to work and if the final system is similar then maybe you can, although I would at the very least place 220R resistors in series with the I2C lines from the Prop. That way no destructive current could possibly flow and the low values will not interfere with logic levels. But how will the EEPROM chip be powered normally? Maybe a simple Schottky from main Vdd and a bit of extra capacitance would suffice.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • Peter, that is a really good point. In my tests I sometimes saw the unpowered Prop make really definite square wave pulses, about 500 mv and 50 msec or so before it obviously crashed. I have no idea or theory why it did that -- and it did it very infrequently -- but there is definitely some Not According to Hoyle stuff happening while those EE pins are powered without Vcc. At this point if it was my project I would be planning on a DPDT switch or relay.
  • Peter JakackiPeter Jakacki Posts: 8,197
    edited 2019-03-02 - 10:50:51
    localroger wrote: »
    Peter, that is a really good point. In my tests I sometimes saw the unpowered Prop make really definite square wave pulses, about 500 mv and 50 msec or so before it obviously crashed. I have no idea or theory why it did that -- and it did it very infrequently -- but there is definitely some Not According to Hoyle stuff happening while those EE pins are powered without Vcc. At this point if it was my project I would be planning on a DPDT switch or relay.

    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.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • I’m still hacking-up smurfs of various colors, but my brain is coming back so its a good time for an update!

    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!
  • Peter JakackiPeter Jakacki Posts: 8,197
    edited 2019-03-08 - 22:44:33
    The "back-feed" current is not just going through a "diode", it is going through the substrate that all the transistors and diodes are built up on, so don't expect it to behave normally. Power on the CPU with a separate I/O supply that holds the Prop in reset when it is not active is the best solution. Alternatively I would encourage you not to use any kind of switch but just try those 220R resistors in the I2C lines from the Prop and also add a low value across the Prop's supply to ground to load any minor currents. You can use 1K but if you are not worried about current drain during normal use then you can use 220R there as well. This is a quick and easy thing to test and easy to modify a board for because even if you didn't want to end up using it, you have the option of using zero ohm resistors or links for the I2C

    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).

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • should pulling reset down keep the prop from interfering or do I miss something here?

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.