I'm using an I2C EEPROM IC in a project to store configuration and settings for a Teensy Microcontroller, and I'm currently trying to work out how to achieve reprogramming of the settings. I plan on using a desktop app of my own design to communicate via a serial link to another microcontroller which will do the actual writing of the EEPROM.

I opted to go with a 2x3 header (with the receptacle for an IDC ribbon cable) that connects directly to the IC, with a blocking diode to prevent the "programming module" connected via the 2x3 programming port from powering the rest of the project.

In my included schematic, +3V3 is power from the microcontroller in the main project. If power is instead being provided from the programming port, directly to VI2C, it should only be able to power the IC, nothing else on the board.

If power is received via +3V3, will the diode that's in series with the two resistors impact the operation of the I2C bus? The EEPROM is the only I2C device. If it does, is there anything I can do to mitigate those issues?



There's a few problems. Designing circuits that are only partially powered are hard unless you know a lot about how the ICs are designed.

When 3.3V supply provides 3.3V, the 25LC512 is powered via the diode which drops some voltage. If the diode is approximated to drop about 0.7V, the VI2C supply for the EEPROM is about 2.6V. That is very close to the 2.5V minimum voltage limit it has.

As also the pull-ups go to VI2C, the varying current via the bus pull-up resistors when either EEPROM or MCU pulls the wire down will cause the VI2C to vary based on consumption. And there is no bypass caps of any size on the VI2C node.

The I2C bus also does not go up to 3.3V, so hopefully that is enough for the MCU to understand as logic high level, but it does reduce the noise margin.

If the 3.3V supply is unpowered and a programming device applies voltage to VI2C directly, there can be even more issues. As the I2C bus wires are pulled up via resistors, they get pulled up with the unpowered MCU on the bus, and depending on which MCU you are using, it may try to backfeed the MCU supply voltage via tie MCU I2C bus pins and this also means the I2C bus pins may not go high enough for communicating properly between the programming device and EEPROM.

It might simply be easier to have a single 3.3V supply and let the EEPROM be programmed via Teensy, or powering up the whole 3.3V supply and keep the Teensy in reset in order to access the EEPROM while the Teensy does nothing.

  • \$\begingroup\$ I would just note that at the current required by this circuit, the diode would drop only a fraction of 0.7 V. \$\endgroup\$ Sep 20 at 6:31
  • \$\begingroup\$ @VladimirCravero 0.5 is a fraction of 0.7, yes. Include the tolerances in both the power supply and the IC and you do have a problem. \$\endgroup\$
    – fraxinus
    Sep 20 at 7:47
  • \$\begingroup\$ So I spent a while to take the responses on board and have decided to follow the advice you gave in the last paragraph of your answer. I've instead changed the six-pin connector to connect to a serial port and I'm now using two of the pins to put the Teensy into a "programming mode" using an IO pin and an interrupt. The programming module shorts the IO pin to ground and this triggers an ISR routine which handles the programming to emulate this standby stage. I'm then going to reset, either by calling the init routines again or by actually resetting the Teensy once I find out how to reset a 4.1 \$\endgroup\$
    – Jamie
    Oct 11 at 5:41
  1. You need to think about the voltage drop across the diode (You can assume 0.7V for a bulk standard diode). Make sure the rail voltage specifications for your I2C eeprom do allow this in case the 3V3 rail is used. You also should add decoupling capacitors to your device on the VI2C line (100nF and 1uF) for good measure. Also make sure, that your application mcu's I2C port pins are in so called HIGH-Z mode during power off. In Short: There must be no backfeed into the devices. This applys to all devices on the bus!
  2. As I2C is a 'open collector' type bus, there schould be no problem, as long as the 3.3V - 0.7V bus voltage is within the safe operational spectrum of your mcu's I2C port. Make sure, that these signal levels (add margins, e.g. 25%) are well within the typical specification of your controller I2C ports. This may sound trivial, but do not forget about your noise margin! Errors introduced by these scenarios are a pain to track down! Take special care about the lower threshold here. You also could add another 100nF capacitor on the VI2C line close to the pullup's - just for good measure again.
  3. In conclusion: This design will, if the points above apply, work as desired. You could use a diode type with low voltage drop to make your solution more predictable - devices with ratings as low as 300mV are available and cheap. But here comes the catch: As there is always a voltage drop across the diode, you need to validate your design. If it is for hobby use only: Good to go. For professional use: Consider that the voltage drop and the acceptable thresholds change with temperatur and device age. Also make sure that other devices on the I2C bus may be affected.
  4. Also think about the use case of the connection port as a whole. Will it be used in the field? Then think about adding ESD-protection and fusing to the connector. Will it only be used in production? No ESD-protection required. Is it single time use? Do not add a header - just add the pads for a bed of nails or pressure type connection. Is your requirement even valid: Is the power seperation even required? Just add a connector and programm the eeprom while there is no bus activity by the mcu (assuming single master). This can be achieved by holding the controller in reset mode. Then the mcu can be powered up without any problem during the write process. You can control this behaviour with your external programmer mcu or a hardwired connector as well. Is the external programmer required? You could programm the I2C via your application mcu. This mcu could establish a usb connection to your host applocation and forward the data to the eeprom via I2C. Is a eeprom even requried? You can store your configuration the application mcu's flash easily!
  5. My two cents (Under the assumption, that an external eeprom is required and the programmer must be used): As you have a 6 pin connector, go with these signals: 3V3, GND, I2C_SDA, I2C_SCL, !Reset and Status. 3V3 in this case is the main rail from the external programmer. There is no problem in it powering the application mcu as well. As soon as your external programmer desires to write to the eeprom, it drives the reset low an thereby 'disables' your mcu. After the whole write process is finished the application mcu does a 'reboot' and should check a special byte in the eeprom. If this byte holds a flag it should read the entire eeprom and validate its contents based on some sort of checksum. This checksum can also be stored in the eeprom as it is computet by your desktop app. The result is then signaled to the programmer via the status line. Please do not forget to add a pullup resistor on the reset line. Also the status signal should be of open collector type - this allows some kind of bidirectional interface.
  6. I have seen and used this kind of implementation many times - works just fine and is suitet for production and field type interfaces (Field interfaces need to be ruggedized). It is simple and realiable, but allows for a wide variaty of extensions. E.g: Your programmer can also perform a checksum validation after the write process. Your application MCU can listen to the status line and then establish a I2C connection to your programmer MCU als Slave - you can use the line to signal the application mcu to go into slave mode and so on ....
  • 1
    \$\begingroup\$ ElectronicsStudent - Hi, Please do not include greetings, sign-off, signature or other chit-chat as it breaks this site rule. I have removed them for you, this time. Stack Exchange is not a forum. I recommend you read the site tour. Thanks. \$\endgroup\$
    – SamGibson
    Sep 19 at 19:00

Instead of a diode, use an ideal diode made up of a P-channel MOSFET with the gate to ground. It will work just like a diode, but it will have 0 voltage drop, avoiding the issues others have brought up.

Ideal diode circuit



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.