EEPROM Broken after some hundred writes

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
Hi community, I'm Marco from Italy, I'm an electronic developer and I like automation in general.

I would like to share my problem with community, to know what do you think about this.
I'm developing an electronic board for general automation purposes, on this board there is a STM32F104 that communicate cia i2c with an eeprom.
I've bought eeprom from LCSC to try them, model is Zetta ZD24C128A (datasheet here: https://datasheet.lcsc.com/lcsc/2011180305_Zetta-ZD24C128A-SSGMB_C918271.pdf)

There are 800 parameters (double byte) that are stored in eeprom. On startup, I read all 800 parameters and I store them in RAM for use them.
When I edit some parameters (using an user interfaces with display and buttons), MCU will store them in eeprom successfully (I think that at most in this way you can change 1 or 2 parameters every second, not more).
And so far everything is ok.
Problem is when I use a function that I've implemented, that reset all 800 parameters. I need this function to initialize the board and factory settings.
This function is a cycle that put 0 in all parameters, then write them to eeprom. Eeprom writes are delayed of 5 milliseconds between them.
When I start this function, I think eeprom breaks, because if I power cycle the board, every single operation on eeprom return me "BUS BUSY" (that means mcu can't communicate with eeprom).

In your opinion, could there be a possibility that Eeeprom Zetta ZD24C128A are faulty or very very bad quality?
Any of you have had experience with a low quality like this?

Thanks in advance,
Marco
 

MrChips

Joined Oct 2, 2009
30,708
Welcome to AAC!

Before putting blame on the EEPROM I would do some independent testing. Make the assumption that the EEPROM is good. Test the EEPROM on a system that is different from your prototyping board.
Make sure that the I2C is rock solid. Examine connection lengths, clock speed, supply voltage, power supply decoupling, etc.
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
Welcome to AAC!

Before putting blame on the EEPROM I would do some independent testing. Make the assumption that the EEPROM is good. Test the EEPROM on a system that is different from your prototyping board.
Make sure that the I2C is rock solid. Examine connection lengths, clock speed, supply voltage, power supply decoupling, etc.
I’ll do that tests, connection lenght are 35mm, and the board has all decoupling capacitor, maybe I think that I need to examine i2c bus with a scope.
Marco
 

dl324

Joined Mar 30, 2015
16,845
Welcome to AAC!
In your opinion, could there be a possibility that Eeeprom Zetta ZD24C128A are faulty or very very bad quality?
I think you should test the EEPROM out of your circuit first.

EDIT: correct typo (missing E)

When I edit some parameters (using an user interfaces with display and buttons), MCU will store them in eeprom successfully (I think that at most in this way you can change 1 or 2 parameters every second, not more).
That sounds abusive to the EEPROM to me. Since EEPROMs have limited program/erase cycles, it would be better to keep changes in RAM and only write when the system is powered down. Or after a certain number of changes have been made or the user requests a store operation. That could reduce the number of erase/write operations significantly and prolong the lifetime of the device.

If you do frequent writes, you should consider some sort of wear leveling algorithm.
 
Last edited:

Ian0

Joined Aug 7, 2020
9,667
Have you taken into account that the 24C128 has to be written in 64-byte pages, and there is a 10ms write cycle for each page?
During the write cycle, the device refuses to respond. Writing 1600 bytes will take quarter of a second.
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
Welcome to AAC!
I think you should test the EEPROM out of your circuit first.

EDIT: correct typo (missing E)

That sounds abusive to the EEPROM to me. Since EEPROMs have limited program/erase cycles, it would be better to keep changes in RAM and only write when the system is powered down. Or after a certain number of changes have been made or the user requests a store operation. That could reduce the number of erase/write operations significantly and prolong the lifetime of the device.

If you do frequent writes, you should consider some sort of wear leveling algorithm.
Hi, I save parameters every time that I edit them for two reasons:
1-Parameters editing occurs very rarely, I think a maximum of 10 times in all lifetime of device, for some of them, for other 1 or 2.
2-There isn't a device power down procedure. Device is supplied by mains with a plug, then when user take off the plug, system will power down. I've not think about capacitors or backup battery for reason "1".

But your advice to consider a wear leveling algorithm is ok, I think I will implement it in the future.

Thanks, Marco
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
Have you taken into account that the 24C128 has to be written in 64-byte pages, and there is a 10ms write cycle for each page?
During the write cycle, the device refuses to respond. Writing 1600 bytes will take quarter of a second.
Ouch, I think I've made some mistake...
Pages ok, I organized the parameters in different pages. But what about 10ms? I thought it was 5...
But now, I have a doubt:
If I need to put a value in, for example, the 23th byte of page no 122, I need to rewrite all page 122 or only the 23th byte? What happen if I effectively write only 23th byte?
 

Ian0

Joined Aug 7, 2020
9,667
Ouch, I think I've made some mistake...
Pages ok, I organized the parameters in different pages. But what about 10ms? I thought it was 5...
But now, I have a doubt:
If I need to put a value in, for example, the 23th byte of page no 122, I need to rewrite all page 122 or only the 23th byte? What happen if I effectively write only 23th byte?
I'm going from the Atmel datasheet (because I've never heard of Zetta). You can write just the one byte, but it still takes 10ms.
In most cases you can check whether it has finished by writing the first byte of the I2C message and seeing if you get an acknowledge.
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
I'm going from the Atmel datasheet (because I've never heard of Zetta). You can write just the one byte, but it still takes 10ms.
In most cases you can check whether it has finished by writing the first byte of the I2C message and seeing if you get an acknowledge.
I'll try it asap..
Me too I've never heard of Zetta. I've tried it because a chinese PCBA factory offered me an alternative code because he has nothing else in stock.
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
Hi, I've done some tests on my board, but all seems to be ok. Capacitance, lenght, signals, all seems to be good.
Is it possibile to break an eeprom if I communicate too fast or if I send too much commands without wait between them?
I've try to replace the eeprom with an On Semiconductor's one and doesn't change anything, eeprom goes ok for a while, then when I start to write on it a hundred of data (with interval of 10mS) breaks.
Pullup resistors are 4k7 and voltage is 3v3, I think is ok.
Lenght of trace is 15mm, far from other components.
I2C is set on fast mode, but I've tried in standard mode too.
I use HAL functions, especially HAL_I2C_Mem_Write and HAL_I2C_Mem_Read, and when i debug the code, i2c function return always BUS_BUSY as a result of a timeout.
Is it possible that I wrongly write in a particular memory address that broke the eeprom? I think not, but..
I'm groping in the dark, I've just a mound of died eeprom on desk and I can't understand where is the problem.
 

Thread Starter

marcotecnovolt

Joined Sep 6, 2022
9
What do you see if you look at the SDA and SCL lines with an oscilloscope?
Hi, I did some tests on circuit, and some more indepth measuremente with oscilloscope. Last time I've looked for the problem in the wrong place (supply, correct communication protocol etc).
Signal on SDA and SCL lines is not very square, then I think pullup resistors on bus are too big.
I tried to replace them with a 2k2 instead of 4k7 that are on project. signal is better and eeprom works good, without problems.
I think problem is resolved, but I need your advice or opinion.

Thanks for all,
Marco
 
Top