Forum: Mikrocontroller und Digitale Elektronik NAND mit TAmega32 ansteuern


von Michael S. (redrabbit)


Angehängte Dateien:

Lesenswert?

Ich bin ganz neu hier und will erstmal hallo sagen:

Hi, ich bin der Michi, hab vor Kurzem mein Elektrotechnikstudium 
angefangen und bisher nur teilweise Erfahrung mit Analog- und 
Digitaltechnik.
Auch im Bereich der Microcontroller bin ich noch recht unerfahren.


Ich habe vor einen NAND-Flash(Hynix HY27US08281A) mit einem ATmega32 zu 
beschreieben und auszulesen. Dazu will ich die Daten vom PC per 
RS232-Schnitstelle auf den µC übertragen.

Da der NAND mit 3,3V arbeitet, muss ich den µC leider auch mit 3,3V 
betreiben. (oder alle Daten- und Controlpins mit nem Pegelwandler 
ausstatten)
Wenn ich das Datenblatt richtig verstanden habe, taktet der mega32 bei 
3,3V nurnoch mit max 8MHz. Somit fällt die Kommunikation mit dem PC über 
USB schonmal ins Wasser, weil dafür min. 12MHz notwedig sind.

Ich schreibe das Programm für den µC mit Programmers Notepad, compiliere 
mit WINAVR und beschreibe den µC mit avrdude und dem DIAMEX USB ISP.
Bisher bin ich soweit, dass ich die Device ID des NANDs auslese und mit 
den ersten Teil des Rückgabewertes per blinkender LED ausgeben lass. 
(sieh main.c und NAND.c im Anhang)
Nur leider bekommen ich nur Kauderwelsch zurück :/
Ich hab per Fuses den Jtag Port schon abgeschaltet, weil ich deine Pins 
als Controlpins für den NAND brauche.
Die Pegel der Controlpins habe ich gegenüber der Angaben im Datenblatt 
deshalb invertiert, weil ich aus Erfahrung weiß, dass wenn CE nicht 
verbunden ist, der NAND tot ist.

In den Anhang habe ich auchnoch zwei Fotos meines Aufbaus, sowie den 
zugrundeliegenden Schaltplan gepackt. (sry, aber ich bin nicht so gut in 
Eagle CAD ;) ).

Kann mir jemand von Euch vllt. sagen, woran es liegen könnte?

mfg
Michi

von Stefan F. (stefan1987)


Lesenswert?

Hallo Michael,

ich kann dir zwar leider nicht direkt bei deinem Problem helfen, aber 
der Grund warum noch keiner geantwortet hat könnte zum einem daran 
liegen das du die Files im .rar Foramt angehängt hast und zum anderen 
das es knapp 8 Mb sind. (Wusst ich erst auch nicht das .rar eher 
unbeliebt hier ist)

Du könntest zb. schonmal ca 4 Mb sparen wenn du das Datasheet vom Atmega 
32 rausnimmst. Und die Bilder könnte man auch noch komprimieren.

Viel Erfolg bei deinem Vorhaben.

Grüße
Stefan

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Ausserdem hast du auf deinem Breadboard den Pin 30 (AVCC) des ATmega32 
nicht angeschlossen.

von Hans Peter B. (Gast)


Lesenswert?

Auf der SW-Seite solltest du nochmals die Bit-Manipulation an den Ports 
studieren.
http://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC/_Register
Hans Peter

von Peter D. (peda)


Lesenswert?

Ne, 8MB packe ich nicht aus.

Du solltest den Flash als externen Memory anschließen, also mit 74HC573 
Adreßlatch. Die überzähligen Adressen legt man an einen Port als 
Page-Select.
Damit ist dann der Zugriff ganz easy (per Pointer).


Michael Stoffels schrieb:
> Bisher bin ich soweit, dass ich die Device ID des NANDs auslese und mit
> den ersten Teil des Rückgabewertes per blinkender LED ausgeben lass.
> (sieh main.c und NAND.c im Anhang)

Bring erstmal die UART zum laufen und nimm die für Debugausgaben.


Peter

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Nimm dochn Mega324, der macht die 12MHz auf 3,3V.
Allerdings lieber erstmal mitm UART spielen, USB ist selbst mit der 
V-USB lib ne Nummer höher.

von Michael S. (redrabbit)


Lesenswert?

Zur Dateigröße: Ich bin es aus anderen Technikforen gewöhnt, dass man 
möglichst viele Informationen anhängt, damit diejenigen, die einem 
helfen möchten nicht im Nebel stochern. sry

von Michael S. (redrabbit)


Lesenswert?

Das mit dem 74HC573 verstehe ich nicht richtig. Ist das nicht einfach 
ein 8-bit parallel zur parallel Schieberegister. So wie ich das im 
Datenblatt des NANDs verstanden habe, ist das timing kein Problem, weil 
ich die Datenausgabe ja über RE steuern kann.

Ja, das mit dem USART hab ich mir heut morgen auch gedacht ;)

von Peter D. (peda)


Lesenswert?

Michael Stoffels schrieb:
> Zur Dateigröße: Ich bin es aus anderen Technikforen gewöhnt, dass man
> möglichst viele Informationen anhängt

Viele Informationen und Aufblähen ist aber ein Unterschied.

Für Datenblätter gibt man nur den Link darauf an.
Und Fotos kann man zuschneiden und leicht komprimieren, ohne das die 
Qualität leidet.
Schau Dir mal Fotos in anderen Beiträgen an, >200kB bringt nichts mehr.
Die großen Fotos sind oft sogar schlechter.

Z.B.:
Beitrag "Zeigt her eure Kunstwerke (2)"


Peter

von Peter D. (peda)


Lesenswert?

Michael Stoffels schrieb:
> Das mit dem 74HC573 verstehe ich nicht richtig.

Ups, der Mega32 hat kein Memory-Interface.
Das geht nur mit z.B. ATmega162, ATmega128.


Peter

von Miška (Gast)


Lesenswert?

Die Schaltung sollte für's Erste i.O. sein - ein Bustreiber ist hier 
überflüssig, der Mega32 kann sowieso keinen externen Speicher 
adressieren.
Ich würde PRE noch einen Pull-down und WP einen Pull-up spendieren.
In Deiner NAND.c setzt/löschst Du mit jedem PORTC-Zugriff immer nur 
genau einen Pin, die anderen werden dabei LOW - das ist sicher nicht 
Deine Absicht. (siehe Hans Peter B.)
PORTC = (0<<x) Was soll das?
Schiebe mal eine Null hin und her, was erhältst Du als Ergebnis?
--> C-Sprachreferenz studieren (Bit-Operationen!).

von Michael S. (redrabbit)


Lesenswert?

ok, das mit den Widerständen mach ich mal auf jeden Fall.
Alles was ich über die AVRs weiß, hab ich aus dem Anfängertutorial hier 
ausm Forum.
Und da hab ichs so verstanden, dass "PORTC = (0<<PCx)" im Port C Pin 
xauf LOW setzt.
Aber ich les mir das mal besser nochmal durch.
Danke :D

von Frank K. (fchk)


Lesenswert?

Das solltest Du Dir merken:

1. Nie eine LED ohne Vorwiderstand oder andere Strombegrenzung 
betreiben.
2. Niemals Eingänge unbeschaltet lassen, es sei denn, es ist im 
Datenblatt ausdrücklich erlaubt.
3. Der R/!B Ausgang ist Open Collector bzw Open Drain. Das heißt: Dieser 
Pin kann das Signal nur gegen Masse ziehen, aber nicht gegen VCC. An so 
einen Pin gehört ein Pullup-Widerstand, wobei der AVR auch interne 
Pullups hat, die man aber erst einschalten muss.

fchk

von Michael S. (redrabbit)


Lesenswert?

Vielen Dank, das werd ich mal ausprobieren und mir merken ;)

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Michael Stoffels schrieb:
> Vielen Dank, das werd ich mal ausprobieren und mir merken ;)

Und AVCC nicht vergessen!

von Michael S. (redrabbit)


Lesenswert?

Das hab ich schon erledigt ;)
Hab mich vorher schon über die geringe Stromaufnahme gewundert xP

von Erich (Gast)


Lesenswert?

Wo ist der Informationsgewinn, wenn jeder immer Kopien der Datenblätter 
an sein Zeugs mit dranpackt?

Warum kann man nicht einfach einen Link auf die .PDF des 
Bauteileherstellers anfügen?

Sind das alles Facebookleute inzwischen?

Gruss

von Michael S. (redrabbit)


Lesenswert?

Also, ich habe jetzt folgendes geändert:

- R/B und WP mit 10K an 3,3V gesetzt.
- PRE mit 10K an GND gesetzt.
- in main.c und NAND.c "PortX = (1<<PBY)" in "PortX |= (1<<PBY)" 
geändert
- in main.c und NAND.c "PortX = (0<<PBY)" in "PortX &= ~(1<<PBY)" 
geändert.
- AVCC mit 3,3V verbunden, sowie das gazugehörige GND mit GND.

Leider krieg ich immernoch 144 zurück. Eigentlich sollte es 173 sein.
Hab ich eigentlich die Funktion N_GetDeviceID() in NAND.c richtig 
impementiert? (So wie im Datenblatt des Hynix HY27US08281A auf Seite 30 
beschrieben)
Ich habe die Signal gegenüber dem Graph auf besagter Seite invertiert, 
da ich aus Erfahrung weiß, dass der NAND tot ist, wenn CE nicht 
verbunden ist.

von Michael S. (redrabbit)


Angehängte Dateien:

Lesenswert?

Nein, dass hat ein meine Augen was mit Arbeitserleichterung zu tun.
Aber wenn das hier aus Speicherplatzgründen, oder Anderen nicht 
gewünscht wird, werde ich es in Zukunkt lassen. Leider kann ich den 
ersten Post mit dem Dateianhang nicht mehr editieren.
Deshalb hab ich hier nochmal NAND.c angehängt.
Was hat das hier bitte mit Facebook zu tun?!

von Miška (Gast)


Lesenswert?

Die Bitoperationen sind jetzt i.O.
Sieh Dir mal im Datenblatt das Timing genau an (Fig. 17):
1. CLE=LOW, CE=HIGH, WE=HIGH, ALE=LOW, RE=HIGH
2. CE=WE=LOW, CLE=HIGH
3. DDRA=Alles auf Ausgang, 0x90 auf IO0..7 (PORTA0..7)
4. WE=HIGH
5. CLE=HIGH
u.s.w.

Deine Sequenz ist falsch. Du programmierst:
CE=HIGH, WE=HIGH, CLE=LOW, PORTA=0x90 u.s.w.

Das passt nicht.

von Michael S. (redrabbit)


Lesenswert?

Danke :)
Das hab ich fast befürchtet :/
Ich schau nochmal intensiv drüber.

von Michael S. (redrabbit)


Lesenswert?

@ Miška:

Du setzt in 1. ALE auf LOW, bevor du 0x90 ausgibst. In Fig. 17 ist ALE 
HIGHT, bis 0x90 eingelesen ist. Soweit ich weiß steht ALE für "Adress 
Latch Enable". Wenn ich die Pin Beschreibung richtig verstanden habe, 
ist ALE also ein Eingang, mit dem gesteuert wird, ob der Input an den 
I/O Pins in den Adressregister oder Comand/Data-Register laufen soll.
Auch verstehe ich nicht, wieso Du CE auf LOW setzt. Führt das nicht 
dazu, dass der NAND auf Standby geht?

Ich galub ich hab da irgendwo nen Knoten im Hirn :)

mfg
Michi

von Miška (Gast)


Lesenswert?

Michael Stoffels schrieb:
> Du setzt in 1. ALE auf LOW, bevor du 0x90 ausgibst. In Fig. 17 ist ALE
> HIGHT, bis 0x90 eingelesen ist.
Nein, ALE geht HIGH, nachdem die 0x90 eingelesen wurde (WE=0->1, siehe 
unten).

> Soweit ich weiß steht ALE für "Adress
> Latch Enable". Wenn ich die Pin Beschreibung richtig verstanden habe,
> ist ALE also ein Eingang, mit dem gesteuert wird, ob der Input an den
> I/O Pins in den Adressregister oder Comand/Data-Register laufen soll.
Richtig.

> Auch verstehe ich nicht, wieso Du CE auf LOW setzt. Führt das nicht
> dazu, dass der NAND auf Standby geht?
CE ist LOW-aktiv. Du solltest Dir nochmals "Table 2" und "Table 6" sowie 
Kapitel 2 "Bus Operation" zu Gemüte führen, da steht alles beschrieben.
Ein '#' hinter dem Namen bedeutet, daß der Pin LOW-aktiv ist.
In Table 6 siehst Du dann auch, daß der Chip in Standby geht, wenn CE 
HIGH ist.

In Fig.17 ist der zeitliche Ablauf zum Auslesen der ID dargestellt. Ich 
habe nur einen Teil davon wiedergegeben.

Hier einmal etwas ausführlicher:
1. Muß der Chip ausgewählt werden --> CE=LOW. Gleichzeitig teilst Du ihm 
noch mit, daß Du ihm einen Befehl (CLE=1, ALE=0) senden (=schreiben -> 
WE=LOW, RE=HIGH) willst.
2. Übermittelst Du den Befehl (0x90=Read ID) -> WE=LOW->HIGH (siehe 
Table 6, Zeile 1, 'Command Input': eine Schreiboperation findet mit der 
LOW->HIGH-Flanke des WE-Pins statt)
3. Jetzt muß dem Chip noch die Adresse 0 (Punkt 3.6 "Read ID") 
übermittelt werden -> CLE=0,ALE=1
4. Adreßbyte 1 schreiben: IO7..0=0x00, WE=LOW, dann WE=HIGH (analog 2.)
5. Punkt vier noch zweimal wiederholen, da drei Adreßbytes benötigt 
werden.
6. Nun kannst Du die ID lesen (-> WE=1, ALE=0 und tAR (10ns) abwarten)
7. Das Datenbyte wird auf IO7..0 mit der HIGH-LOW-Flanke von RE 
ausgegeben (tREA (30ns) beachten!)
8. Nach zweimal RE=HIGH->LOW hast Du die beiden ID-Bytes.
9. RE=HIGH, CE=HIGH, fertig.

HTH

von martin (Gast)


Lesenswert?

Ich kann dir ATMega32U2 bzw U4 nahelegen.
Die haben Hardware-USB, und das tuts eigentlich immer.
Die LUFA-Lib ist ganz brauchbar dafür!

Grüße, Martin

von Michael S. (redrabbit)


Lesenswert?

Vielen Dank Miška :D
Ich habe jetzt das implementiert, was du vorgeschlagen hast.
Auch habe ich nochmal alle Verbindungen nachgemessen und überprüft ob 
alles richtig belegt ist. => Alles ok ;)

Leider krieg ich nur 1000111 = 71 = 0x47 als Marker Code zurück. Der 
sollte aber 0xAD = 173 = 10101101 sein :(

Hat jemand ne Idee, woran das noch liegen könnte?



Das mit dem ATMega32U2 ist auch sehr interessant. Für mich wird das aber 
erst wichtig, wenn es darum geht größere Datenmengen zu transportiern.


mfg
Michi

Bitte 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
Noch kein Account? Hier anmelden.