Hallo Zusammen, nach der Umstellung auf SMD (ich weiß, ich bin spät dran) habe ich mit den Atmel Speichermodulen AT24C512C folgendes Problem. Nach 3 bis 6 maligem kompletten Beschreiben des Speichers und anschließendem Auslesen, sind einige wenige Speicherzellen defekt, d.h. nicht mehr beschreibbar. In einem Speichertest beschreibe ich den kompletten Speicher abwechselnd mit 2 verschiedenen Muster und lese diese dann wieder aus. Als Controller verwende ich einen ATMEGA 1284P-AU, 20MHz im 5V Betrieb. Die 5V liegen auch stabil an, auf dem Scope kann ich auch keine Auffälligkeiten sehen. Der Speicher ist für 5,5V Betrieb zugelassen und hat auch die richtige Kennung aufgedruckt. Mein erster Verdacht war, das ich da die 3,6V Variante erwischt habe, was aber nicht der Fall ist. Von 6 verschiedenen Speicher ICs sind 4 Stück bereits defekt, nur 2 Speicher haben bisher 30 mal den Speichertest komplett überstanden. Die gleiche Schaltung und Software habe ich schon viele Jahre im Einsatz (allerdings mit bedrahteten Bauteile), bisher ohne Probleme. Hat jemand einen Tip für mich ? Gruß Jan
Jan M. schrieb: > sind einige wenige Speicherzellen defekt, d.h. > nicht mehr beschreibbar. Wie stellst Du das fest? Was schreibst Du rein, was liest Du zurück?
Zuerst schreibe ich 55(h) in den kompletten Speicher und lese ihn dann komplett aus und vergleiche. Dann mache ich das gleiche mit AA(h). Auslesen tue ich in den defekten Zellen dann immer den Wert, der beim letzen korrekten Schreiben dort drin war. Die ersten 3-6 Mal ist alles in Ordnung und dann sind halt einge Zellen defekt und es steht dort immer der gleiche Wert drin. Gruß Jan
Jan M. schrieb: > Hat jemand einen Tip für mich ? AT24C512C nicht mehr bei AliExpress bestellen ? SMDs nicht mit Schweißbrenner löten ? Vor dem löten nicht 10 Bier reinlöten ?
:
Bearbeitet durch User
Jan M. schrieb: > Auslesen tue ich in den defekten Zellen dann immer den Wert, der beim > letzen korrekten Schreiben dort drin war. Welche Pullups, Du kannst bis auf 1,8k runter gehen. Gehe mal mit dem I2C-Takt auf 100kHz runter. Prüfe, ob das Delay nach dem Schreiben wirklich >=5ms ist oder benutze ACK-Polling.
Hallo Peter, als I2C Takt verwende ich schon 100kHz. Pullup verwende ich schon seit Jahren 1,5k , bisher immer ohne Probleme. Der Delay ist auf 5ms eingestellt. Kann ich den durch die Ansteuerung den Chip wirklich kaput machen? Die ersten 6 Mal klappt es ja, nur wenn der Fehler einmal auftritt, dann bei diesem Chip permanent. Bin da wirklich ratlos. Mir ist die mögliche Ursache noch nicht klar: # Hardwarefehler in der Beschaltung ? # Spikes in der Versorgung ? # Fehler in der Ansteuerung ? # defekte Charge ? Habe mir jetzt Speicher von der Firma ON Semiconductor bestellt, mal sehen wie die sich verhalten. Gruß Jan
Jan M. schrieb: > Der Delay ist auf 5ms eingestellt. Und hast Du das auch geprüft? Probier einfach mal 20ms. Ich nehme immer ACK-Polling.
Habe leider hier am Platz gerade kein Scope, also habe ich das delay auf 20ms erhöht. Damit dauert der Speichertest erheblich länger, aber der bereits "defekte" Speicherbaustein macht die gleichen Fehler wie mit 5ms. Ob ein "neuer" Speicher dann nicht mehr zerstört wird, wird die Zeit zeigen. Gruß Jan
spendiere mal dem 100nF Kerko nen Elko Bruder mit 10µF vielleicht geht die Spannung mit der Zeit in die Knie probiere mal ein anderes Muster beim Schreiben 0b00000001 und 0b01111111. Aufjedenfall würde ich aufs ACK warten als eine feste Wartezeit verwenden, um das Programm unabhängig vom µC Takt zu machen.
Hallo Peter, ich versuche mich gerade am ACK-Polling, stehe da aber irgendwie auf dem Schlauch. Schreibvorgang bisher: i2c_start_wait(i2cEEPROM+I2C_WRITE); i2c_write(EE_TX_Zeiger >> 8); i2c_write(EE_TX_Zeiger); i2c_write(wert_byte); i2c_stop(); _delay_ms(5); Anstelle des Delay muss man jetzt auf das Ack warten. Hast du da evtl. ein Beispiel für mich ? Gruß Jan
Bevor du am Schreiben verzweifelst, Jan M. schrieb: > Auslesen tue ich in den defekten Zellen dann immer den Wert, der beim > letzen korrekten Schreiben dort drin war. das sieht doch eher so aus, als ob das Löschen nicht klappt.
Von Löschen vor dem Schreiben habe ich bisher nichts gelesen, ich dachte das macht der Chip von alleine. Gruß Jan
Hallo Jan M. schrieb: > Schreibvorgang bisher: > > i2c_start_wait(i2cEEPROM+I2C_WRITE); > i2c_write(EE_TX_Zeiger >> 8); > i2c_write(EE_TX_Zeiger); > i2c_write(wert_byte); > i2c_stop(); > > _delay_ms(5); > Oh, shit. Dir ist schon klar das die 24C512 blockweise schreiben? D.h. wenn du nur ein Byte schreibst werden in Wirklichkeit 128 geschrieben. Die Tatsächlichen Write-Cycles sind also in wirklichkeit 128 mal so viele wie du meinst. da1l6
da1l6 schrieb: > Dir ist schon klar das die 24C512 blockweise schreiben? D.h. wenn du nur > ein Byte schreibst werden in Wirklichkeit 128 geschrieben. > Die Tatsächlichen Write-Cycles sind also in wirklichkeit 128 mal so > viele wie du meinst. Wo steht das im Datenblatt?
Kiesel schrieb: > Wo steht das im Datenblatt? Nirgends. Sowohl der AT24C512 als auch der neuere AT24C512B und C Typ erlauben zwar auch PageWrite mit 128 Bytes, aber ein einzelnes Byte zu schreiben ist genauso erlaubt. Dabei wird auch nirgends erwähnt, das das immer einem PageWrite auslöst. Wenn der TE alle Chips aus einer Charge bezieht, würde ich da einen Fehler vermuten und mal auf ein anderes Produkt ausweichen.
:
Bearbeitet durch User
Aus dem Datenblatt des 24LC1025: When doing a write of less than 128 bytes the data in the rest of the page is refreshed along with the data bytes being written. This will force the entire page to endure a write cycle, for this reason endurance is specified per page.
:
Bearbeitet durch User
Georg G. schrieb: > Aus dem Datenblatt des 24LC1025: > > When doing a write of less than 128 bytes > the data in the rest of the page is > refreshed along with the data bytes being > written. This will force the entire page to > endure a write cycle, for this reason > endurance is specified per page. Wenn man dies auf den AT24C512C übertragen kann, dann ist nach 3 - 6maligen komplett beschreiben (siehe TO) jede Page mit dem 128fachen "belastet". Das erklärt aber noch lange nicht den Ausfall der Chips, da jede Page 10^6 Schreibzyklen verkraftet.
Georg G. schrieb: > Der Beitrag sollte deine Frage beantworten. > > Kiesel schrieb: >> Wo steht das im Datenblatt? Es gab schon eine Antwort: Beitrag "Re: Probleme mit AT24C512C, nach mehrmaligem beschreiben Defekt"
Georg G. schrieb: > Aus dem Datenblatt des 24LC1025: Das mag alles sein, es geht hier aber um den AT24C512C. In dessen Datenblatt ist das nicht zu finden.
Kiesel schrieb: > Georg G. schrieb: >> Aus dem Datenblatt des 24LC1025: >> >> When doing a write of less than 128 bytes >> the data in the rest of the page is >> refreshed along with the data bytes being >> written. This will force the entire page to >> endure a write cycle, for this reason >> endurance is specified per page. > > Wenn man dies auf den AT24C512C übertragen kann, dann ist nach 3 - > 6maligen komplett beschreiben (siehe TO) jede Page mit dem 128fachen > "belastet". Das erklärt aber noch lange nicht den Ausfall der Chips, da > jede Page 10^6 Schreibzyklen verkraftet. Ich kann das bestätigen. Ich testet mal so einen Speicherbaustein und brachte es auf fast 14^6 Page Schreibzyklen bis sich Fehler zeigten. Das waren allerdings AT24C1024s. Pattern war 0x55 und 0xAA. Die Ratings scheinen also sehr konservativ zu sein. Busgeschwindigkeit war 400kb. 3K3 PU bei 5V. Nach Ausfall waren auch viele benachbarte Zellen schadhaft. Ein interner PIC EEPROM brachte es auf ähnliche Werte. Ich würde denselben Test mit Bausteinen aus sicherer Quelle wiederholen. mfg, Gerhard
Habe gestern endlich die alternativen Speicher von der Fa. ON Semiconductor(CAT24C512WI-GT3) bekommen und eingelötet. Diese sind deutlich günstiger als die Atmel. Bisher laufen drei Platinen ohne Probleme im Dauertest. Werde das weiter beobachten. Habe da wohl eine "schlechte" Charge oder Fake Speicher erwischt. Obwohl alle Speicher bisher von renomierten Lieferanten geliefert wurden. Gruß Jan
Gerhard O. schrieb: > Ich kann das bestätigen. Ich testet mal so einen Speicherbaustein und > brachte es auf fast 14^6 Page Schreibzyklen bis sich Fehler zeigten. Das > waren allerdings AT24C1024s. Pattern war 0x55 und 0xAA. Die Ratings > scheinen also sehr konservativ zu sein. Eine Flash-Zelle gilt als defekt, wenn die spezifizierte Data Retention Time nicht mehr eingehalten wird. Du musst also nach dem letzten Schreibzugriff zehn Jahre warten, erst dann kannst Du beurteilen ob der Baustein defekt ist oder nicht. Wenn der Baustein schon dermassen schrottreif ist, dass die Zellen direkt nach dem Schreiben einen Fehler liefern, dann wären Deine Daten darin auch schon etliche tausend Zyklen eher nich mehr sicher gewesen.
Jan M. schrieb: > Obwohl alle Speicher bisher von renomierten Lieferanten geliefert > wurden. Von wem konkret? Sind diese offiziell als authorisiertrr Distributor bei microchip gelistet? Wenn ja dann sofort eine failure analyse forden, wenn nein draus lernen und nur bei authorisierten distis kaufen. Dasselbe könnte dir mit jedem Bauteil schnell passieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.