Problem mit NAND an ATmega32

Hallo liebe Gemeinschaft,

Ich bin ganz neu hier und möchte mich erstmal kurz vorstellen. Ich bin der Michi und beginne bald mein Elektrotechnikstudium. Bisher habe ich mich etwas mit Digitaltechnik und Analogtechnik beschäftigt. Eingestiegen bin ich mit den AVR-Controllern und mein derzeitiges Problem bezieht sich auch auf einen Vertreter dieser Familie.

Mein momentanes Vorhaben ist es, einen NAND, es handelt sich hierbei um einen HY27US08281A von Hynix, mit einem ATmega32 über RS232 anzusteuern. Ich besitze ein RAW-Abbild eines baugleichen NANDs, welches auch die spare-Informationen enthält und 1:1 auf meinen NAND kopiert werden soll. Bisher gelingt es mir die korrekte Device ID auszulesen, ASCII-Text abzuspeichern und identisch wieder auszulesen. Zu Testzwecken wollte ich die ersten 527 Bytes eine JPG-Bildes auf eine page + spare schreiben. Leider scheinen unter bestimmten Bedingungen Bytes mit dem Wert 0xff übersprungen zu werden. Ich habe mal meine Beschaltung und den Quellcode angehängt. In "daten.zip" befinden sich zwei bin-Dateien. "vorher.bin" enthält die Daten, die ich in den NAND geschrieben hab und "nacher.bin" konnte ich auslesen. Zur Sicherheit habe ich 3 mal in Folge ausgelesen und immer das selbe Ergebnis erhalten. Hat Irgendjemand von Euch eine Idee, woran das liegen könnte, bzw. wie ich das beheben kann? Ich möchte noch erwähnen, dass ich R/B nicht beschaltet habe, sondern den Controller einfach kurz warten lasse, da der Controller doch um einiges langsamer, als der NAND ist.

mfg
Michi

Wilkommen im Forum. Ich habe mir das Programm nicht angeschaut, aber könnte es sein das der Flash defekt ist? Ist der neu oder gebraucht? Könnte es sein das Blöcke gesperrt sind (Kommando "Lock Block" bzw "Lock Tight")?

PS: Das ist kein NAND sondern ein NAND Flash, ein NAND ist ein Logik Baustein.

MfG Hannes

Ja, das habe ich mir auch erst gedacht. Aber der NAND-Flash wurden als neu verkauft und ich habe auch mit dem Mikroskop keine Rückstände von Lötzinn gefunden. Die Pins haben diese ganz feinen Riefen, wie es bei neuen Chips eigentlich normal ist. Ja, das war von mir ein wenig "umgangssprachlich" ausgedrückt. Ich meine kein negieres UND-Gatter ;)
ASCII Text kann ich ja auch über die komplette Page schreiben. Deshalb denke ich nicht, dass es gesperrt ist.
Ich habe diesen Defekt auch schon bei anderen, baugleichen chips festgestellt. Ich werde das ganze mal an den Logicanalyser hängen und hoffen, dass der Controller was falsch überträgt. Aber da es bei ASCII keine Probleme gibt, befürchte ich, dass mir das nicht weiter helfen wird. Ich hatte gehofft, das hier Jemand schonmal ein ähnliches Problem hatte, oder ich in meiner Beschaltung irgendwas falsch gemacht hab.

mfg
Michi

So, ich habs jetzt hinbekommen.
Falls jemand das selbe Problem hat und diesen Threat über google gefunden hat, möchte ich hier abschließend schreiben, woran es bei mir lag.
Ich musste meinen Programmablauf mit Wartezeiten versehen (siehe Beispiel). 3 µSek haben sich als ganz gut rausgestellt. Ist noch nicht optimiert, funktioniert aber.


Beispiel:

Code:

---

for(int i=0; i<length; i++)
  {
        PORTB |= (1<<PB0);
 
                PORTC &= ~(1<<WE);
                _delay_us(3);
                        PORTA = RS_receive();  //Data Input
                _delay_us(3);
                PORTC |= (1<<WE);
                _delay_us(3);
  }

---