This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PM: TM4C123 erases occasionally the internal EEPROM when disconnecting USB connection.

Part Number: TM4C123GH6PM

Hi

I am using TM4C123GH6PM in my design using USB for data communication. Sometimes the value stored in the internal EEPROM has been changed by itself with disconnecting USB connection.

The board is powered up from USB.

Please let me know if you have any solution.

Thanks

  • majid said:
    Sometimes the value stored in the internal EEPROM has been changed by itself with disconnecting USB connection.

    Perhaps this procedure adds more data for analysis:

    • Had you checked & confirmed this key EEPROM value - immediately prior - to such disconnecting?
    • Do you use more than a single such EEPROM value?     If so - what percentage of those used have changed?
    • Are you confident that the proper procedure for EEPROM Data Saving has been followed?     Loss of data - upon power removal - suggests that the data (may) not have been fully/properly "saved."

    Boards powered from USB - when "disconnected" - may suffer (both) power & ground "bounce" due to the purely mechanical method of (usual) USB plug removal.    If all 3 of the previous "analysis steps" have proven out - perhaps a properly "debounced means" of USB Power removal may be attempted - and then tested.

    It is also possible to power from (other) than USB - that (differing) power method should be tried and tested - and will reveal if (really) USB disconnect (as claimed) is the culprit...

  • cb1_mobile said:
    Boards powered from USB - when "disconnected" - may suffer (both) power & ground "bounce" due to the purely mechanical method of (usual) USB plug removal.

    And because of that I would ask if you are using an external supervisory IC.

    Robert

  • Note that the worst case EE programming time is measured in seconds. Does your power supply holdup last long enough to ensure completed writes if the power is disconnected mid-write?

    Robert
  • Robert Adsett said:
    And because of that I would ask if you are using an external supervisory IC.

    That's a most worthwhile suggestion - yet (unknown) is "how impacting" the (normal/mechanical) USB disconnect proves to (even) a "supervised" MCU.    (might the MCU - under such power bounce conditions - "eat its young?")     I fear - that point - is (little) or unknown.    (i.e. how would vendor's (usual) "MCU die test suite" accommodate?)

    In theory - use of a proper, "Supervisory IC" (should) overcome "bad power" - provided the MCU (fully) respects its (supervisor controlled) Reset Input...    (we have noted cases when they do NOT!)

    I return to the (necessity) to test the "success" of EEPROM Programming via use of a proper (non-USB cable) Power Supply - first & foremost!    Only then can such EEPROM issues be (really) cast at the feet of, poster's claimed, "USB Disconnect."

  • cb1_mobile said:
    Robert Adsett
    And because of that I would ask if you are using an external supervisory IC.

    That's a most worthwhile suggestion - yet (unknown) is "how impacting" the (normal/mechanical) USB disconnect proves to (even) a "supervised" MCU.    (might the MCU - under such power bounce conditions - "eat its young?")  

    This is one of the kinds of use case supervisory circuits are designed for. They hold the micro in reset long enough for the power supply not only to reach a proper level but also to stabilize. One of the key parameters of such a supervisor is the time it holds the device in reset after it has reached operating voltage. Another is how low a power supply voltage can it maintain reset.

    That leaves the hole on power bounce to be whether the 'EE' logic has any region where it ignores the reset. Given the errata list that would not shock me. In fact given the errata list or the programming time I would not use the 'EE' for dynamic updates. The OP must read the errata.

    cb1_mobile said:
    I return to the (necessity) to test the "success" of EEPROM Programming via use of a proper (non-USB cable) Power Supply - first & foremost!    Only then can such EEPROM issues be (really) cast at the feet of, poster's claimed, "USB Disconnect."

    Oh, I doubt it's USB related. It's almost certainly a power issue given what's presented so far. Such a test would confirm that though and is not a bad idea.

    Robert

  • Robert Adsett72 said:
    Oh, I doubt it's USB related. It's almost certainly a power issue

    Reviewing my writings - that is (exactly) what I suggested!     The issue IS "power caused/related" and that is due to the "Power Bounce" wrought by USB cable removal from a "USB Powered board."

    Powering from a "proper power source" proves best means to eliminate (or confirm) "USB Disconnect caused Power Bounce" as "prime suspect."

    Note too that we (both) agree that vendor's EEPROM must be treated w/"kid gloves" - and proves (most) vulnerable to such "Power Issues."