Speicherzugriff führt zu Fehlverhalten

[Daniel P. (pfefferk)]

Guten Tag liebe Gemeinde!

Ich habe mal wieder ein Problem an dem ich mir schon seit mehreren Tagen 
die Zähne ausbeiße.

Ich führe gerade einige Übertragungstests mit dem ATmega128RFA1 durch. 
Dazu Habe ich einen Transmitter der eine bestimmte Anzahl von Frames mit 
bestimmter Größe sendet. Der Empfänger soll diese empfangen und anhand 
eines bestimmten Bytes im Frame entscheiden, ob es sich um einen 
"Mess-Frame" handelt. Die Unterscheidung ist wichtig, da der Sender dem 
Empfänger mitteilt, wann beide den Kanal wechseln.

Empfängt der Empfänger einen solchen "Mess-Frame", soll der LQI-Wert 
(Indikator der Signalqualität) gespeichert werden, da beim Kanalwechsel 
eine Bestimmung des durchschn. LQIs erfolgt.

Zur Speicherung wird eine global definierte Matrix verwendet (uint8_t 
test_vec[2][NUMBER_OF_FRAMES_PER_BLOCK]).

Sobald ich allerdings in meiner Routine

void doReceiverEval(void)

 schreibend auf diese Matrix zugreife, läuft reproduzierbar etwas schief
(UART "verschluckt" sich).

Der in der funktionierenden Version auskommentierte Befehl

test_vec[0][(uint8_t)num_rcvd_packets] = lqi;

resultiert in:
(r15 = LQI-Wert, 0x03D8 = niederwertiges Byte von num_rcvd_packets)

     test_vec[0][(uint8_t)num_rcvd_packets] = lqi;
     3d6:  e0 91 d8 03   lds  r30, 0x03D8
     3da:  f0 e0         ldi  r31, 0x00  ; 0
     3dc:  ee 5d         subi  r30, 0xDE  ; 222
     3de:  fc 4f         sbci  r31, 0xFC  ; 252
     3e0:  f0 82         st  Z, r15

Das Fehlverhalten tritt unabhängig vom cast oder der Dimension des 
Arrays auf. Auch bei einem Vektor werden ab einem Gewissen Punkt falsche 
Werte gelesen und der UART gibt einen Mix aus "vernünftigem" Text und 
dem y mit zwei Punkten aus.

Dies ist mittlerweile die zweite Version des Codes. Ich hatte Code mit 
ähnlicher Struktur. Da trat das Phänomen auf, dass ich innerhalb der 
switch-Umgebung schreiben konnte, diese Werte aber nach Verlassen nicht 
mehr lesbar waren. Stattdessen wurden wieder alte Werte gelesen. 
Deswegen vermute ich, dass es sich um einen gedanklichen Fehler 
meinerseits handelt.

Hat jemand eine Idee was da schiefgeht?

Ich bin für jede Idee/jeden Hinweise offen und dankbar.

[Stefan E. (sternst)]

Wie groß ist NUMBER_OF_FRAMES_PER_BLOCK? Der Ausgabe in 
uart_out_does_not_work.txt nach tippe ich auf die Schnelle mal auf 8.

Nirgendwo sehe ich irgendein Rücksetzen von num_rcvd_packets. Wie ist 
also sichergestellt, dass es innerhalb der durch 
NUMBER_OF_FRAMES_PER_BLOCK vorgegebenen Grenze bleibt?

[Daniel P. (pfefferk)]

NUMBER_OF_FRAMES_PER_BLOCK ist 10 und in einer anderen Datei definiert.

Stimmt, ich setze es nicht zurück. Das habe ich beim Neuschreiben 
anscheinend vergessen. Wird sofort getestet.

----- TEST -----

Es liegt an der Grenze!

Ich habe beim Neuschreiben geschlampt. Vielen Dank für den Hinweis!

Jetzt werde ich Stück für Stück wieder die volle Funktionalität einbauen 
und gucken ab wann ich den nächsten Fehler entdecke.

Vermutlich komme ich wieder zu meinem "alten Fehler" zurück. :D