Ich habe in einem Projekt einen übertakteten Atmega1284P (22.1184MHz wegen Baud-Rate) durch einen AVR128DB48 ersetzt der mit 24MHz läuft. Im ersten Projekt habe ich die SD-Card via 74CD4050 Als Level Converter angeschlossen. Zwischen dem Atmega1248P und dem 74CD4050 ist ein IDC Kabel von etwa 15cm Länge, der SPI Clock entspricht der halben CPU Frequenz, also ca. 11MHz. Es funktioniert einwandfrei. Bei der Neuauflage habe ich jetzt einen AVR128DB48 genommen, weil dort sind die Pegelkonverter schon eingebaut. D.h. Port C kann man mit einer anderen Spannung als der Rest betreiben (MVIO Feature) werden. Auch habe ich nun den SD-Card Slot auf die gleiche Platine gelötet wie der AVR128DB48. Die Leiterbahnen dazwischen sind alle kürzer als 5cm und kreuzen sich nicht mit anderen Signalen. Aber trotzdem mehr als 4MHz SPI Clock schafft das Konstrukt nicht. Pullup an MISO, DAT1 und DAT2 ist vorhanden (2k2). Hat mir jemand Tipps wie ich das Problem angehen soll? Oder fällt jemanden etwas ein was ich unbedingt beachten sollte?
Ein Scope anschliessen und nachsehen was vorgeht. Bandbreite >= 100 MHz, jeden Tastkopf mit kurzer Klammer an Masse. SPI Decodierung wäre nett. Gruss
Peter S. schrieb: > Ich habe in einem Projekt einen übertakteten Atmega1284P (22.1184MHz > wegen Baud-Rate) durch einen AVR128DB48 ersetzt der mit 24MHz läuft. > > Im ersten Projekt habe ich die SD-Card via 74CD4050 Als Level Converter > angeschlossen. MÖÖÖP! Es gibt keinen 74CD4050, bestenfalls 74HC4050. > kreuzen sich nicht mit anderen Signalen. Aber trotzdem mehr als 4MHz SPI > Clock schafft das Konstrukt nicht. Was heißt das? Brennt dann dein IC ab oder gibt es Kommunikationsfehler? Oder kannst du nicht mehr als 4 MHz einstellen? Zeig mal dein Layout und Schaltplan.
Peter S. schrieb: > Hat mir jemand Tipps wie ich das Problem angehen soll? Mit dem Oszi messen und die Signalqualität direkt an den SD-Kartenpins und dann auch direkt an den Controllerpins auf Anstiegszeit, Überschwinger und Einkopplungen kontrollieren.
Peter S. schrieb: > Hat mir jemand Tipps wie ich das Problem angehen soll? Oder fällt > jemanden etwas ein was ich unbedingt beachten sollte? Messen würde helfen ;-) ich tippe mal auf Verzögerungen durch die ganzen Buffer und so weiter. Vermutlich irgendwelcher 70er-Jahre Schrott im DIL-Gehäuse? Das Übertakten ist natürlich auch kontraproduktiv. Das SPI-Peripheral des ATMEGA ist vermutlich nicht für so hohe Frequenzen gedacht und könnte auch zum Problem beitragen. Generell gehen SD-Karten auch mit 20MHz problemlos. Ich habe das in mehreren Projekten mit STM32 und PIC32 verwendet, und hatte nie Probleme. Sogar auf dem Breadboard (PIC32MX250). Ich wäre ja nie auf die Idee gekommen, einem Atmega eine SD-Karte aufzubürden. Es gibt da passendere Lösungen, wie Nor-Flashes mit SPI. Sowieso: Wenn man einen ATMEGA übertakten muss, dann ist wirklich ein schnellerer µC angebracht. Bei einem 32-Bitter kann man gleich FATFS verwenen und Daten im .csv-Format loggen. Zu einem Bruchteil des Stromverbrauchs. Allein schon weil man nicht mit 5V herumbrät.
Da das Problem sehr sporadisch auftritt habe ich noch nicht ganz genau gesehen was dann passiert. Ich konnte es sozusagen noch nie in flagranti erwischen. Dass es am SPI clock liegen könnte (das ist auch nur eine Vermutung) kam mir erst gestern in den Sinn als ich mit dem Debugger feststellte, dass er in der SPI read routine hängt warum auch immer. Daraufhin habe ich den Takt runter gesetzt und seit dem ist das Problem weg. Aber eben es erklärt nicht die Ursache. Ja der Pegelkonverter hiesst 74HC4050. Ich werde wohl den Oszi anschliessen müssen (ewig nicht mehr gebraucht) und schaue mal ob mir da etwas auffällt, ich melde mich dann wieder.
Name: schrieb: > Messen würde helfen ;-) > > ich tippe mal auf Verzögerungen durch die ganzen Buffer und so weiter. > Vermutlich irgendwelcher 70er-Jahre Schrott im DIL-Gehäuse? Er hat gar keinen Buffer mehr! Mit Buffer ging es! Das > Übertakten ist natürlich auch kontraproduktiv. Das SPI-Peripheral des > ATMEGA ist vermutlich nicht für so hohe Frequenzen gedacht und könnte > auch zum Problem beitragen. Blödsinn! Gerade das SPI ist da vollkommen unkritisch, ist ja nur eine Schieberegister. Übertakten macht eher dem Flash, EEPROM zu schaffen. > Bei einem 32-Bitter kann man gleich FATFS verwenen und Daten im > .csv-Format loggen. Das kann auch ein ach so kleiner AVR! Been there, done that! > Zu einem Bruchteil des Stromverbrauchs. Allein schon > weil man nicht mit 5V herumbrät. Auch AVRs laufen auf 3,3V. Und mit etwas Köpfchen und Sleep Mode ist auch ein AVR sehr sparsam, wenn es denn sein muss. Trotzdem Danke für denen wertvollen Beitrag!
Peter S. schrieb: > Dass es am SPI clock liegen könnte Ja, könnte. Hast du schon mal am Takt eine Serienterminierung versucht? Das erklärt aber nicht ganz, warum es mit einer langsameren Taktfrequenz geht. Peter S. schrieb: > Ich werde wohl den Oszi > anschliessen müssen (ewig nicht mehr gebraucht) und schaue mal ob mir da > etwas auffällt, Das wäre wohl das allererste gewesen, was ich gemacht hätte, noch lange bevor ich hier gefragt hätte ... 😀
Peter S. schrieb: > Da das Problem sehr sporadisch auftritt habe ich noch nicht ganz genau > gesehen was dann passiert. Ich konnte es sozusagen noch nie in flagranti > erwischen. Das deutet alles auf ein Signalqualitätsproblem am Takt hin. Dein neuer AVR ist nicht nur neuer, sondern auch deutlich schneller und giftiger als der gute, alte 74HC4050 Buffer. Die Flankensteilheit ist höher, die Anstiegszeit kleiner. Damit bekommst du, vermutlich auch wegen einiger Unsauberkeiten im Layout, Störungen der Taktflanke, welche die Kommunikation aus dem Tritt bringt. Abhilfe schafft hier eine Serienterminierung des Takts, siehe Wellenwiderstand. > er in der SPI read routine hängt warum auch immer. Daraufhin habe ich > den Takt runter gesetzt und seit dem ist das Problem weg. Nicht wirklich, es tritt nur seltener auf. Entscheidend ist die Flankensteilheit, nicht die Frequenz. > Ja der Pegelkonverter hiesst 74HC4050. Ich werde wohl den Oszi > anschliessen müssen (ewig nicht mehr gebraucht) und schaue mal ob mir da > etwas auffällt, ich melde mich dann wieder. https://www.mikrocontroller.net/articles/Oszilloskop#Tastk%C3%B6pfe_richtig_benutzen
Falk B. schrieb: > Er hat gar keinen Buffer mehr! Mit Buffer ging es! Haha, den braucht er aber. Weil die SD-Karte wird 5V-Signale nicht lieben.
Name: schrieb: > Haha, den braucht er aber. Weil die SD-Karte wird 5V-Signale nicht > lieben. Du solltest das mit dem sinnerfassenden Lesen nochmal üben. "Bei der Neuauflage habe ich jetzt einen AVR128DB48 genommen, weil dort sind die Pegelkonverter schon eingebaut. D.h. Port C kann man mit einer anderen Spannung als der Rest betreiben (MVIO Feature) werden."
Name: schrieb: > Falk B. schrieb: >> Er hat gar keinen Buffer mehr! Mit Buffer ging es! > > Haha, den braucht er aber. Weil die SD-Karte wird 5V-Signale nicht > lieben. Ich wiederhole mich, darum habe ich das MVIO Feature des AVR128DB verwendet. Port C und die SD-Karte werden mit einem eigenen Spannungsregler mit 3V3 versorgt. Der Rest braucht 5V weil er eine etwas in die Jahre gekommene Schaltung bedienen muss. Alles ist SMD (ausser der alte Teil). Also kein DIL Schrott. Das mit der Serienterminierung werde ich mal ausprobieren. Der AVR128 ist moderner, aber darum muss er ja nicht giftiger sein. Aber ich könnte ja mal die Slew-Rate Limitations am Port C aktivieren. Bezüglich Taktrate, im Datenblatt des AVR128 steht dass der SPI nur 10MHz unterstützt, das hat mich immer etwas verwundert. Aber wer weiss vielleicht steckt da was dahinter.
Name: schrieb: > Vermutlich irgendwelcher 70er-Jahre Schrott im DIL-Gehäuse? Der AVR128DB48 ist von August 2020!
Stefan ⛄ F. schrieb: > Der AVR128DB48 ist von August 2020! Genau lesen ist Trumpf. Damit waren sehr eindeutig die Buffer gemeint. Die, wie wir inzwischen wissen, nicht existieren. Beißreflex eines AVR-Fanboys? Ich habe nicht geschrieben dass alle AVR-Nutzer dumm sind, sondern dass der AVR mir für die Anwendung (SD-Karte) etwas klein dimensioniert erscheinen will. Das hat NICHT die gleiche Bedeutung ;-) Was das Thema angeht: Entweder wir haben einen Softwarefehler, oder einen Hardwarefehler. Um das zu unterscheiden sollte man sich mal ganz allgemein die Signale ansehen. Stimmt der Pegel? Passen die Taktflanken ausreichend zu den Daten? Sind die Flanken sauber? Bei den Margins die TTL-Signale haben, sollte man potentielle Probleme mit der Signalqualität einigermaßen einfach sehen können. Idealerweise beurteilt man das nach objektiven Kriterien (Setup/hold-Zeiten bei send/receive, Flankensteilheit, Pegel), erfühlen oder auspendeln hilft weniger.
Danke für die Tipps, die Stossrichtung der Fehlersuche ist damit vorgegeben. D.h. zuerst LA vom Tisch räumen und den Oszi anschliessen und natürlich die Software durchleuchten (der Teil der sich mit dem SPI beschäftigt). Ich habe nicht erwartet, dass man mein Problem löst, dazu waren die Angaben zu wage. Es ging mir vor allem darum zu hören, was andere als nächsten Schritt machen würden. Ich dachte das hätte ich eigentlich so gefragt.
Was ich in solchen Fällen gern tue: Wenn man den Fehler in Software erkennt, kann man sich einen GPIO setzen um das DSO zu triggern. Im Idealfall kann man vergleichen was der Debugger sieht und was am Oszi zu sehen ist, und sich physikalisch das kaputte Bit ansehen. Bisher waren es bei mir IMMER Softwarefehler ;-)
Hallo, bevor du aufwändig Serienwiderstände einbaust kannst du auf dem Port das Slewrate Feature aktivieren und ausprobieren.
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.