Akausales Verhalten von Atmega328p

Bei der Hardware handelt es sich um einen Arduino Uno und ein LoRa 
Shield von Dragino, wobei ich mit der MCU das darauf befindliche RFM95W 
LoRa Modul ansteuere. Ich programmiere per AVRDUDE aber direkt mit Atmel 
Studio, das ganze soll erst später auf eine eigene Platine übertragen 
werden. Ich kann die Layouts gerne raussuchen, aber einen Hardwarefehler 
halte ich daher erstmal für unwahrscheinlich, zumal die Konfiguration 
bisher gut funktioniert hat. Stack/Pointer Fehler klingt plausibel, ich 
werde mal weiter danach suchen, vielen Dank!

Philipp H. schrieb:
> Ich programmiere zur Zeit ein aufwändigeres Projekt für den Atmega328p
> in Atmel Studio 7
Ich sags mal so: weil der nur 32k Speicher hat, kannst du damit gar kein 
wirklich "aufwändiges" Projekt machen.

> wie z.B. das Überschreiben von einzelnen Adressen im Speicher mit
> willkürlichen Werten
Der klassische amoklaufende Pointer durch zu kleine oder sich 
überlappende Arrays.

> Kann es trotzdem am Speicher liegen
Ja, wenn du z.B. in einer Subroutine ein kleines Integer-Array mit 512 
Werten im lokalen Speicher anlegen willst, dann ist die Speicherlatte 
trotz einer "Data Memory Usage" von 0% gerissen...

Philipp H. schrieb:
> aufwändigeres Projekt für den Atmega328p
"aufwändigeres Projekt" ist schon ein heftiger Widerspruch bei so einem 
uralten vermurksten Steinzeit Krüppel:-)

Dein Problem hört sich stark noch sowas hier an:

https://de.wikipedia.org/wiki/Puffer%C3%BCberlauf

Moin,

mir fallen eingentlich nur 2 Sachen ein, von denen 1 passiert und man 
das 2. nie machen sollte:

1. Pointer läuft zu weit.

2. Pointer in nen vector array gesetzt und läuft weiter.

grüüßee (:

>Bei der Hardware handelt es sich um einen Arduino Uno und ein LoRa
>Shield von Dragino, wobei ich mit der MCU das darauf befindliche RFM95W
>LoRa Modul ansteuere.

Hallo,

auch mein erster Tipp wäre ein Stacküberlauf, vermutlich an mehreren 
Stellen. Zur Ansteuerung des RFM95 samt Umgebung ist die Tiefe der 
Unterprogramme vermutlich zu groß geworden. Also flacher programmieren.


mfG

Dein Problem wirst du dann ernsthaft bemerken wenn du den Code auf einem 
ARM laufen lässt. Der zieht dann den Hard Fault....

Genau vor dem Problem stehen dann die meisten die vom AVR zum ARM 
wechseln. Was da noch durch rutschte wird jetzt zuverlässig durch die 
Hardware verhindert.

Also musst du selber in deinen Programm suchen und das Problem beheben. 
Oder den Teil in dem du es vermutest hier veröffentlichen...

Marco H. schrieb:
> Der zieht dann den Hard Fault....

Seit wann das denn?
Auch dem ARM ist es Schnuppe, wenn Du mit einem Arraypointer auf 
Variablen dahinter zugreifst. Die CPU kann nicht wissen, ob das 
beabsichtigt ist.

Marco H. schrieb:
> Was da noch durch rutschte wird jetzt zuverlässig durch die
> Hardware verhindert.

Quak. 'Zuverlässig' gar nicht und verhindert wird da auch nischt.
Man muss sich auch schon selber einen Überblick über lokale Variablen 
verschaffen, denn 'size' weiss davon nix.

Er reicht vieleicht schon sich die Warnungen des Compilers anzuschauen.

Udo S. schrieb:
> Er reicht vieleicht schon sich die Warnungen des Compilers
> anzuschauen.

Eben und diesen nachzugehen...


Nö Auch bei Array Verletzungen landest du beim ARM im Hard Fault. Das 
kannst du gerne zuverlässig ausprobieren.

Marco H. schrieb:
> Nö Auch bei Array Verletzungen landest du beim ARM im Hard Fault. Das
> kannst du gerne zuverlässig ausprobieren.

Wie soll das gehen?
Der Compiler legt dazu keinerlei Verwaltungsstrukturen an. Die 
User-Applikation kann in ihrem RAM frei rumschreiben, wie sie lustig 
ist. Ansonsten müßtest Du ja für jede Variable definieren, welche 
Funktion darauf zugreifen darf und wie.

Marco H. schrieb:
> Nö Auch bei Array Verletzungen landest du beim ARM im Hard Fault. Das
> kannst du gerne zuverlässig ausprobieren.

Das glaube ich nicht.

Hier ein Beispiel:

1

void foo ()

2

{

3

  uint8_t bar1[100];

4

  uint8_t bar2[100];

5

  uint8_t i;

6

7

  for (i = 0; i < 150; i++)

8

  {

9

    bar1[i] = 42;

10

  }

11

}

Und jetzt erkläre mir mal, wie ein ARM diesen Pufferüberlauf erkennen 
soll.

Maxe schrieb:
> Fehler im Code muessten sich tendenziell nach jedem Hardreset in
> gleicher Weise bemerkbar machen.

Leider nein! Denn es könnte ein von externer Quelle verursachter 
Interrupt dazwischen kommen, der den Fehler verursacht - das aber nur, 
wenn er der Interrupt einer bestimmten Stelle im Hauptprogramm auftritt. 
So kann das Fehlverhalten zu einem Zufallsgenerator werden.

Maxe schrieb:
> Fehler im Code muessten sich tendenziell nach jedem Hardreset in
> gleicher Weise bemerkbar machen.

Ähhhh, ich hab mal Temp.Werte hingeschrieben wo sie nicht 
hingehören.....

Arduino Fanboy D. schrieb:
> Naja, zumindest der AVR GCC meldet das:

Mensch, das war doch nur ein exemplarisches Beispiel mit der fixen 
Grenze von 150 und ein Denkanstoß.

Dann mach ichs halt anders:

1

void foo (uint8_t limit)

2

{

3

  uint8_t bar1[100] = { 0 };

4

  uint8_t bar2[100] = { 0 };

5

  uint8_t i;

6

7

  for (i = 0; i < limit; i++)

8

  {

9

    bar1[i] = 42;

10

  }

11

}

12

13

void bar ()

14

{

15

    foo (rand() % 150);

16

}

Jetzt wird der Compiler nix mehr ausrichten können. Und schon gar nicht 
wird ein ARM einen Hardfault werfen. Solange man im verwendeten 
Adressraum bleibt, ist alles erlaubt.

> Unter anderem, um solche Böcke zu vermeiden, wurde sowas erfunden:

Reden wir von C oder von C++?

Oh,oh schrieb:
> Das hilft dem TO bei Problemen mit dem Atmega328 bestimmt genau so viel,
> wie des Verhalten von ARM.

Es ging darum, dass dem TO erzählt wurde "Mit einem ARM wär das nicht 
passiert". Das ist aber ein Trugschluss.

Wo ist denn Dein Beitrag zur Hilfe? Dieser war's jedenfalls nicht.

Tipps wurden dem TO bereits genannt. Aber: Ohne Quellcode bleibt alles 
Spekulation. Solange der hier nicht präsentiert wird, kann man nur aus 
der Glaskugel lesen.

m.n. schrieb:
> Der TO sollte die Größe testweise um 50% erhöhen.

Beim AVR-GCC kann man den Stack nicht vergrößern. Er läuft immer bis 
RAM_END. Um ihn zu vergrößern, müßte man die globalen Variablen 
verkleinern.

Peter D. schrieb:
> Beim AVR-GCC kann man den Stack nicht vergrößern. Er läuft immer bis
> RAM_END. Um ihn zu vergrößern, müßte man die globalen Variablen
> verkleinern.

Eben.

m.n. schrieb:
> Wenn dann der Linker meckert, sieht man ob's RAM zu klein ist.

Nö, der Stack läuft einfach in die globalen Variablen hinein.

Peter D. schrieb:
> Nö, der Stack läuft einfach in die globalen Variablen hinein.

Testbar z.B. mit 
https://www.mikrocontroller.net/attachment/highlight/15782

(Musste etwas suchen, bis ich die Original-PeDa-Version gefunden hab … 
Quelle Beitrag "ATMega32 Stack overflow. Wie vermeiden/analysieren?")

m.n. schrieb:
> Na gut, dann bin ich zu sehr IAR-geschädigt.

Der IAR hat wohl 2 Stacks, einen für Calls/Register und einen für lokale 
Variablen. Daher hat der AVR auch das 3. Pointerset.

m.n. schrieb:
> RAM kann man gut freibekommen, indem man konstante Strings (Texte) nicht
> in initialisierte Variablen kopieren läßt, sondern immer aus dem Flash
> liest.

Da ja nur 31,8% belegt sind, ist das nicht der Flaschenhals.

Erstmal danke für das reichliche Feedback, "aufwändig" war natürlich nur 
im Rahmen der gegebenen Hardware gemeint ;)

Εrnst B. schrieb:
> Testbar z.B. mit
> https://www.mikrocontroller.net/attachment/highlight/15782

habe das mal eingebaut und frage an mehreren Stellen im Programm ab. 
Erwartungsgemäß sinkt der "unberührte" Stack nach den größeren 
Funktionen erheblich ab, z.B. auf 0x02FB von verfügbaren 0x059F, bei 
manchen Durchgängen noch niedriger. Bis er plötzlich wieder auf einen 
höheren Wert springt...? Zerschießt sich das Programm an diesem Punkt? 
Sind dann Fehler bei Pointern/Arrays erstmal unwahrscheinlicher wenn es 
wohl doch einfach am Stack liegt?

Philipp H. schrieb:
> Bis er plötzlich wieder auf einen höheren Wert springt...? Zerschießt
> sich das Programm an diesem Punkt?

Beim Return aus einer Funktion mit größeren lokalen Variablen (Arrays) 
springt der Stackpointer auf einen (wesentlich) höheren Wert.

Ohne den Quellcode kommen wir hier nicht weiter.

Frank M. schrieb:
> Ohne den Quellcode kommen wir hier nicht weiter.

Dann hier mal alle Dateien. lorawan.c ist mit der aktiven Session der 
kritische punkt, dort gehen die Funktionen am tiefsten, vor allem wenn 
frames zusammengesetzt und de/encrypted werden. aes und cmac stammen 
nicht von mir, funktionieren isoliert aber wie erwartet.

Philipp H. schrieb:
> Dann hier mal alle Dateien.

Danke.

Frage dazu:

1

bool LorawanJoinDecrypt (uint8_t *firstElementOfData, uint8_t lengthOfMessage)

Wie groß kann lengthOfMessage werden?

Innerhalb dieser Funktion wird aufgerufen:

1

aes_encrypt(joinAcceptMessageEnc, joinAcceptMessage, &aesContext);

aes_encrypt() arbeitet nicht mit der Längeninformation lengthOfMessage, 
sondern mit einer festen Länge N_BLOCK bzw. Informationen aus 
aesContext.

Ist sichergestellt, dass das gutgeht? aes_encrypt() benutzt zur 
Längenberechnung aesContext(), wobei sich mir nicht direkt auf den 
ersten Blick erschließt, ob und wie lengthOfMessage und aesContext 
korrelieren.

P.S.

Unschön:

1

memset(aesContext.ksch, '\0', 240);

Besser wäre:

1

memset(aesContext.ksch, '\0', (N_MAX_ROUNDS + 1) * N_BLOCK):

oder einfacher:

1

memset(aesContext.ksch, '\0', sizeof (aesContext.ksch)):

Ich habe nachgerechnet: Glücklicherweise stimmen die 240.;)

Tipp: Suche nach weiteren Zahlenkonstanten im Source, überprüfe die 
Richtigkeit und ersetze diese maghischen Zahlen durch passende 
Preprozessor-Konstanten oder sizeofs. Eine falsch verwendete Zahl kann 
schon verheerende Auswirkungen haben.

Noch eine prüfenswerte Stelle in LorawanCreateFrame():

1

  k = i+fOptsLen;

2

  while (i<k)

3

  {

4

    message[i] = macPendingCommand[j];

Ist sichergestellt, dass i + fOptLen niemals größer gleich 127 wird?

Philipp H. schrieb:
> Dann hier mal alle Dateien

Bitte -Wall einschalten und alle Warnungen bearbeiten - nicht durch 
Casts "wegschummeln"

Hard Worker schrieb:
> Plötzlich wird es hier im Thread ganz still

Naja, er hat jetzt erstmal eine Weile was zu tun.

Ich bitte, hier beim Thema zu bleiben. Persönliche Anfeindungen helfen 
hier nicht weiter. Wenn jemand einen Kleinkrieg anzetteln will, ist er 
hier falsch am Platz.

m.n. schrieb:
> Peter D. schrieb:
>> Beim AVR-GCC kann man den Stack nicht vergrößern. Er läuft immer bis
>> RAM_END.
>
> Von RAM_END! Man kann doch den Stackbereich einstellen?

Ja, der Bereich, der dafür vorgesehen ist, kann eingestellt werden. 
Das heißt aber nicht, dass dieser auch eingehalten wird.

> Wenn dann der Linker meckert, sieht man ob's RAM zu klein ist.

Woher soll denn der Linker wissen, wie viel Stack später zur Laufzeit 
tatsächlich verwendet wird? Der sagt dir nur, wie viel Platz deine 
statischen Variablen belegen, sonst nichts. Dass dann für den Stack noch 
genug Platz bleibt (wobei "genug" natürlich stark vom Programm abhängt), 
musst du selbst sicherstellen.

c-hater schrieb:
> Aber von Assembler behauptet eben auch niemand, dass es eine Hochsprache
> wäre. Von einer Hochsprache kann man schon deutlich mehr erwarten als
> von einem Assembler, insbesondere bezüglich der Verhinderung von Fehlern
> und notfalls Möglichkeiten zu ihrer einfacheren Lokalisierung.

An anderen Stellen beschwerst du dich regelmäßig, dass C-Code 
vermeintlich doch so viel größer und langsamer sei als dein 
handgestrickter Assembler-Code. Jetzt beschwerst du dich, dass 
fehlerhafte Zeigerzugriffe und Stacküberläufe zur Laufzeit nicht erkannt 
werden. Das könnte man schon machen, würde aber den Code deutlich größer 
und langsamer machen.

Nachdenklicher schrieb:
>> Akausales Verhalten von Atmega328p
>
> Akausal? Was man hier für wunderschöne Worte finden kann...

Vor allem wird das Verhalten durchaus kausal sein. Wenn man den Grund 
für das Verhalten nicht kennt, heißt das ja nicht, dass es keinen gibt.

Hard Worker schrieb:
> Philipp H. schrieb:
>> Ich programmiere zur Zeit ein aufwändigeres Projekt für den Atmega328p
>> in Atmel Studio 7
>
> Wenn man als einigermassen erfahrener Programmierer das so liest
> dann bekommt man solch einen Respekt vor den Fähigkeiten des TO,
> ganz im Kontrast zu dem was einem dann an Arbeit vorgelegt wird.

Ich habe vieles erst bei diesem Projekt gelernt und es ist alles sehr 
work in progress. Ich verstehe dass es jemandem mit mehr Erfahrung da 
grausen kann, aber jeder fängt mal klein an und der nächste Code wird 
mit Sicherheit deutlich schöner. Ich wollte nur den Verdacht zum 
Ausdruck bringen, dass ich den Chip in Sachen RAM etc. vielleicht an 
seine Grenzen bringe, gerade weil die Programmierung noch sehr holprig 
ist.

Frank M. schrieb:
> Bitte -Wall einschalten und alle Warnungen bearbeiten - nicht durch
> Casts "wegschummeln"

War bereits eingeschaltet, weshalb mich auch wundert, warum ich z.B. 
diese Warnung

Hard Worker schrieb:
> Ich finde beim Compilieren eine bedenkliche Warnung:
>
> ../LoraWAN.c:620: warning: array subscript is above array bounds

nicht bekommen habe. Welche Option übersehe ich da?

Philipp H. schrieb:
> War bereits eingeschaltet, weshalb mich auch wundert, warum ich z.B.
> diese Warnung

Welche gcc-Version hast Du?

Hast Du mal meinen Beitrag von gestern 
Beitrag "Re: Akausales Verhalten von Atmega328p" geprüft?

Da wird aes_encrypt() mit 2 Arrays aufgerufen, die eine variable Länge 
haben, wobei aes_encrypt() hier zwei Array mit fixer Länge erwartet.

Frank M. schrieb:
> Welche gcc-Version hast Du?

"AVR/GNU C Compiler : 5.4.0"

Frank M. schrieb:
> Da wird aes_encrypt() mit 2 Arrays aufgerufen, die eine variable Länge
> haben, wobei aes_encrypt() hier zwei Array mit fixer Länge erwartet.

Habe mich da an anderen Implementierungen der Funktionen orientiert, 
auch dort wird mit variablen Längen aufgerufen. So wie ich das 
verstanden habe werden nur die Blöcke gefüllt, für Nachrichten >16 
müsste man also nochmal mit den restlichen Werten, also verschobenen 
Input/Output Buffern aufrufen. Da sollte durch längere Arrays eigentlich 
nichts in die Wildnis geschrieben werden, im früheren Verlauf haben die 
encrypt Funktionen auch noch kein unerwünschtes Verhalten verursacht. 
Aber ich werde nochmal genauer nachgucken um Fehler auszuschließen.

Arduino Fanboy D. schrieb:
> Was allerdings wohl scheppern muss, ist dieses:uint8_t micBlock[16] =
> {0};
> // schnipp
> for (i=0; i<lengthOfMessage; i++)
> {
>   micBlock[(16+i)] = *(firstElementOfMessage+i);
> }

Das war line 620, ist schon raus. Das mit fOpts ist ok, wird noch nicht 
weiter verwendet.

Philipp H. schrieb:
> War bereits eingeschaltet, weshalb mich auch wundert, warum ich z.B.
> diese Warnung
> Hard Worker schrieb:
>
>> Ich finde beim Compilieren eine bedenkliche Warnung:
>> ../LoraWAN.c:620: warning: array subscript is above array bounds
>
> nicht bekommen habe. Welche Option übersehe ich da?

Manche Warnungen werden vom gcc erst ausgegeben, wenn der Optimizer 
eingeschaltet ist. Also solltest Du mindestens "-Os" setzen, vielleicht 
auch testweise mal mit "-O2" übersetzen.

Frank M. schrieb:
> Manche Warnungen werden vom gcc erst ausgegeben, wenn der Optimizer
> eingeschaltet ist. Also solltest Du mindestens "-Os" setzen, vielleicht
> auch testweise mal mit "-O2" übersetzen.

Merci, mit o2 bekomme ich auch direkt die Meldung über einen anderen 
schön blöden Fehler. Ich Initialisiere Array[16] und schreibe danach in 
Array[16]. Das ist allerdings schon so grundlegend falsch dass ich mich 
frage wie das selbst bei o1 noch durchgehen kann?
Ein Fehler bei dem eine Adresse ohne zutun neu beschrieben wird ist auch 
direkt weg, ich taste mich mal weiter voran und hoffe erstmal, dass das 
der Grund war, sollten die Fehler weiter auftauchen melde ich mich und 
lade das ganze Projekt nochmal hoch.
Vielen Dank erstmal für die rege Beteiligung und die Hilfe, mit mehr 
Erfahrung kommen dann auch hoffentlich kompetentere Fragen!

Hard Worker schrieb:
> Oft fallen Warnings dadurch unter den Tisch dass ein Projekt
> teilweise korrekt compiliert wurde und man nur an der Stelle
> wo ein Fehler auftritt, eingreift.

Dem kann man mit -Werror vorbeugen. Dann muss man an jede Warnung ran 
und keine fällt unter den Tisch.