Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I use the C2 boot mode of 68013a, some times when I power off the 68013 system, it become a unkown device when next reboot, after then I checked the data in EEPROM, find that the PID&VID was rewrote, after a series of power-off test, meanwhile capture the waves on IIC SCL and SDA line, we recreate the problem, in the moment of system power off, some random pulse on SCL and SDA line rewrites the EEPROM.
In my 68013a firmware ,I need to read or write EEPROM, so I connect the EEPROM WP(write protect, active high) pin to Vcc by a resistance, and also connect a 68013a GPIO to WP pin, when I need to write the EEPROM, I set the 68013a GPIO low to deactive the EEPROM write protect, and set it high after write operation. the problem is that, from the wave we capture, in the moment of power off, the EEPROM WP pin is pulled down before the EEPROM is still working, that means when random pulse apears on SCL and SDA, the WP pin is low, and I ensure that no software EEPROM write operation is executing in the moment of power off.
Why is there such a problem? and How to resolve this problem?
I would like to understand what has been written to the EEPROM in a failed condition. Can you provide a dump of EEPROM contents when the failure happens? If you are not writing during power down the situation of corruption of EEPROM during power down is unlikely.
Glitches usually cannot happen to complete a write. The other thing I would suspect is on power up, if the bootloader is writing some contents to EEPROM. The dump of EEPROM values can help analyze the failure better. This may involve further debug, I suggest we create a case and continue more step by step debug. Can you create a tech support case and we can take it further.