Tag zusammen, ich habe folgendes Problem: Beim Empfangen von Daten auf meinem ATMega324PA startet die CPU aus mir vollkommen schleierhaften Gründen neu. Im Anhang ist mein Code zu sehen. Zu Beginn der Main lese ich das MCUSR-Register, setze es auf 0 und gebe den Wert via UART aus. "0xAA 0xBB 0x<Werte>" In der While(1) wird geprüft, ob Daten da sind und gibt bei erfolgreichem Empfang 0x33 auf dem UART aus. Das Problem ensteht wenn ich der MCU von meinem PC aus Daten schicke (5 Byte). Zu Beginn geht alles gut. Doch irgendwann wir wiederholt 0xAA 0xBB 0x00 ausgegeben. In dem MCUSR Register steht nach einem solchen Neustart nichts drin.... Um auszuschließen, dass mir eine andere ISR Ärger macht, habe ich in alle ISR's eine kurze Ausgabe eingebaut um zu prüfen, ob das das Problem ist. Aber leider ohne Ergebnis. Die Ausgaben schauen in etwa so aus: 000000 AA BB 02 33 33 33 33 33 33 33 33 33 33 33 33 33 000010 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 000020 33 33 33 33 33 33 AA BB 00 33 33 33 33 33 33 33 <-- Reset :( 000030 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 000040 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 000050 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 000060 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 000070 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 Da MCUSR nach einem solchen Reset = 0 ist und ich mit dem Oscar schon die Spannung nachgemessen und geprüft habe, gehe ich davon aus, dass es ein Softwareproblem ist.... Vllt. ein Bug in der CPU?! Mein Setup: ATMega324PA @ 14.7456 Mhz, Fuse Bits: Low: 0xFF High: 0xD9, USBASP Programmer, AVR Studio 6 Gruß und Danke, Zitrone
Gast
#3286351
Code? Grüsse, René
Hab die ganze Zeit gedacht:"Denk an den Code!" s. Anhang :)
Gast
#3286367
:-) Ich habe noch nicht so genau geschaut, was mich aber stutzig macht, dass Deine Buffer 16 Byte lang sind, aber für den Index einen uint16_t brauchst. Mir sieht das ganz nach einem Speicherüberlauf aus.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Grüsse, René
Hey René, die Buffer sind gerade 16 Byte groß. Aber dass die Indizes uint16_t sind hat den Sinn, dass ich den Buffer ja auch größer machen kann als 256 Byte und ein uint8_t dann nicht mehr ausreicht.
Hey René, an welcher Stelle siehst du da einen Überlauf?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Ich prüfe ob der Leseindex auf der letzten möglichen Stelle im Array steht und setze ihn dann auf 0 sonnst erhöhe ich ihn. Und der Interrupt schaltet sich selbst aus, wenn keine Daten mehr im Fifo stehen. Oder habe ich an dieser Stelle einen Denkfehler?
Hallo Julian, wenn der transBuffer-Kram in uart0_putc auskommentiert ist, was soll dann die ISR(USART0_UDRE_vect)? Oder bin ich blind? LG, Sebastian
Hey Sebastian, ne du bist nicht blind. ;) Die ISR steht noch drin weil ich sie nicht auskommentiert habe. Aber aufgerufen wird die ISR nicht, da der Interrupt nie "scharf" geschaltet wird. Und das "scharf" schalten ist in uart0_putc() auskommentiert. Die Variante ohne den UDRE-Interrupt sorgt lediglich dafür, dass ich keinen Buffer bemühen muss um die Daten auszugeben. Ich arbeite gerade mit einer Version des USART's die nicht empfangen kann sondern nur sendet und da startet die MCU nicht neu.... Ich werde den Code gleich mal fix auf nen ATMEGA8 portieren und schauen, ob das Problem mit dem Neustart da auch auftritt, dann kann ich wenigstens ausschließen, dass die Hardware defekt ist oder eben nicht....
So,... auf ATMega8 portiert und alles läuft wunderbar. (s. Anhang) Ab und zu kommt mal ein FF rüber statt dem gewünschten Wert aber für sowas gibt es Prüfsummen. Ich gehe jetzt mal von einem Hardwaredefekt auf dem ATMega324pa aus und werde ein paar neue bestellen... Sollte das Problem weiterhin bestehen, werde ich es euch hier wissen lassen... So far