AVR-Debugging: Speicherstelle überwachen

Anton schrieb:
> welche Möglichkeiten gibt es beim AVR-Debugging, eine konkrete
> Speicherstelle zu überwachen
Welcher AVR mit welcher Toolchain?

Ohne genauere Definition hier ein paar Suchbegriffe:
https://onlinedocs.microchip.com/pr/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD-en-US-7/index.html?GUID-1A162E91-DAA7-4E50-AD74-8CF56E5BAC35

Ich wuerd Funktionalitaeten abschalten und schauen, ob's immer noch 
passiert. Allenfalls einen Pin toggeln um zu erkennen, wo der Code 
durchgeht.

Anton schrieb:
> Danke Lothar, das schaut doch schon mal gut aus. Ich hoffe es ist so mit
> einem AVR128DBx Asm-programmiert möglich.

Auch danke, schick - wusste ich noch nicht:

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD-en-US-5/index.html?GUID-F9ABAF2B-36E5-4ABA-AC34-8E63007A1E84

Es ist aber schon klar, dass mit Hardware Debugging das 
Echtzeitverhalten kaputt ist. Denn die MegaAVR haben keinen Hardware 
Tracebuffer, oder Debugregister. Soweit ich weiss. Das laeuft dann ueber 
JTAG, und dauerndes Lesen/Schreiben.

Anton schrieb:
> Bei mir wird ein Stück Speicher falsch überschrieben

Typisch sind das Pointerfehler. Z.B. eine Funktion will 2 Byte 
schreiben, der Pointer zeigt aber nur auf ein Bytearray. Oder das Array 
ist zu klein (Puffer ohne Test auf Arraygrenzen). Oder ein Pointer wird 
an einen Interrupt nicht atomar übergeben.
Die Indexschreibweise ist in der Regel weniger fehleranfällig, als die 
Pointerschreibweise.

>>Purzel H. schrieb:
>> Ich wuerd Funktionalitaeten abschalten und schauen, ob's immer noch
>> passiert.
>
>Das Problem ist der Fehler tritt nur selten unter ungeklärten
>Bedingungungen auf. Das so herauszufinden dauert zu lange.

Ja... ich habe schon Tage(Wochen) an einem Stueck verbracht um solche 
Fehler zu finden. Ich wuensche viel Glueck.

Anton schrieb:
> AVR128DBx Asm-programmiert

Schreib das Programm in C um, das eliminiert schonmal 90% der möglichen 
Fehlerquellen.
Ich hab gemerkt, ab einer Größe von 4..8kB sind Assemblerprogramme nicht 
mehr beherrschbar. Schon bei 2kB Größe fällt es schwer, nach einem Jahr 
wieder durchzublicken.

Anton schrieb:
> Den Fall erschwert daß die Codeausführung maßgeblich von Input der über
> serielle Schnittstellen reinkommt abhängt.

Dann kommt noch hinzu, ob Du auch wirklich ein sauberes fehlertolerantes 
Protokoll definiert und implementiert hast. Alle Signale von außen 
können gestört sein. Du benutzt natürlich einen Quarz und der 
Baudratenfehler ist <1%?

Anton schrieb:
> Purzel H. schrieb:
>> Es ist aber schon klar, dass mit Hardware Debugging das
>> Echtzeitverhalten kaputt ist.
>
> Zum Glück ist das in diesem Fall weitgehend egal.

Wenn auf die Speicherstelle bis zum Auftreten des Fehler schon ein paar 
(tausend) Mal korrekt zugegriffen wird, ist das nicht mehr ganz so egal.

Oliver

Anton schrieb:
> Nein. Die neueren AVRs sind bei den verwendeten Baudraten (9600/19200)
> mit internem Oszillator hinreichend genau

https://www.prosieben.de/tv/galileo/themen/mittwoch-17-dezember-2014/schlaumeier-pferd-vor-der-apotheke-kotzen-sehen

Vermutlich willst Du das Produkt nicht komerziell vermarkten.

Anton schrieb:
> Der Eingabestrom könnte Fehler enthalten die nicht berücksichtigt
> werden. Da das nicht geändert werden kann soll das Programm darüber
> hinwegsehen können.

Dafür muß aber der Programmierer selber sorgen, z.B. mit einem 
Protokoll. Außerdem müssen Pufferüberläufe in jedem Fall abgefangen 
werden.

Die große Frage ist, ob die Beobachtung in Echtzeit erfolgen muss.

Ohne einer Hardwareunzerstützung wid es in Echtzeit nicht möglich sein. 
Speziell bei MCs ohne externen Adress und Datenbus.

1.) Früher baute man eine Bond-Out Version des Chips um direkt ins 
Prozessorinnere sehen zu können. 
https://en.m.wikipedia.org/wiki/Bond-out_processor

2.) Bei neueren Prozessoren gibt es fürs Debugging eine am Prozessorchip 
implementierte Hardware. Stichwort: Hardware Breakpoints. 
https://stackoverflow.com/questions/8878716/what-is-the-difference-between-hardware-and-software-breakpoints

In beiden Fällen ist es möglich eine Exeption(Interrupt) zu setzen wenn 
die zu beobachtende Adresse benutzt wird. Bis an diese Stelle und nach 
dieser Stelle kann der Code in Echtzeit ausgeführt werden. Beim 
Auftreten der Adresse kann fürs Debugging durch die Exeption ein Code 
eingeschoben werden, um Programmzähler und alle anderen internen 
Register zwischendurch auslesen zu können.

Bei MCs ohne Hardwareinterrupt ist der Zugriff auf interne Register nur 
mittels Singlestep möglich. Das Programm funktioniert dann nicht mehr in 
Echtzeit, da gebe es auch die Möglichkeit das Programm auf einer anderen 
Plattform zu simulieren.

Als ersten Schritt würde ich mich informieren ob der MC oder die CPU 
über Hardwarebreakpoints verfügt. Dann könnte man wichtige Daten, wie 
Programmzähler, Stackaufrufhistorie übrr den Exeptioncode in einem 
unverlierbaren Speicherbereich aufheben oder über serielle Schnittstelle 
ausgeben.

Anton schrieb:
> Das Programm ist komplex
Von nix kommt nix. Natürlich neigen gerade "komplexe" (oder auch einfach 
nur "komplizierte") Programme zu Fehlfunktionen. Besonders an Ecken, wo 
man bei der Implementierung von fehlerfreier undgestörter Hardware 
ausgegangen ist.

> die Speicherstelle kritisch
Öffne das Map-File. Finde heraus, wo diese "Speicherstelle" ist. Sieh 
nach, was davor liegt. Gerne auch einige Bytes weiter vorne. Könnte bei 
einer dort liegenden Variable/Array/Puffer so ein amoklaufender 
Pointer/Index die nachfolgenden "Speicherstellen" überschreiben?

Wenn du nicht weiter kommst: sieh zu, dass du vor diese "Speicherstelle" 
leeren Speicher platzierst. Schau dann und wann nach, ob da irgdenwer 
irgendwas reingeschrieben hat. Versuche zu erkennen, was das für Daten 
sind.

Anton schrieb:
> Es ist Assembler Code.
> Daher weiß ich genau und selbstbestimmt was wo ist.

YMMD ;)

Oliver

Anton schrieb:
> Vielmehr werden von irgendwoher (noch) unbekannte Daten in einen
> wichtigen Sendepuffer reingeknallt.
Ist das ein Block oder nur einzelne Bytes? Mitten drin im Puffer oder 
"am Rand"? Immer an der selben Stelle oder immer wieder beliebig 
woanders?

> An und für sich habe ich keinen konkreten Anlass an der Hardware zu
> zweifeln, aber wer bin ich um da was sicher auszuschließen.
Nein, ich meine, dass ich Schaltungen teste, indem ich mit einem 
"Viehtreiber" entwicklungsbegleitend EMV-Tests mache wie im 
Beitrag "Re: Probleme mit Störungen aus dem Netz" 
beschrieben. Machst du solche ähnliche Störfestigkeitstests auch? Es 
reicht z.B. bei einigen Schaltungen schon aus, wenn ich die Weller 
Lötstatiom daneben stelle und die ein- und ausschalte...

> Falls Du auch auf das quarzlose UART abzielst
Nein, tu ich nicht. Ich hab keine Probleme mit so einer Frickelei. Ich 
habe das auch mal gemacht. Aber ich baue jetzt immmer einen Quarz ein.

> arbeitet sogar außen in einer Wetterstation unter Witterungsbedingungen
> absolut unauffällig.
Mein Glückwunsch.
Bei mir hatten halt ca. 2 von 1000 ab&zu Probleme. Und dann fährt ein 
Monteur hin, sucht und flucht 2 Tage herum und tauscht dann das Modul. 
Und das kostet letztlich so viel, da kann ich locker überall einen Quarz 
ranbauen...

Anton schrieb:
> Es ist Assembler Code.
> Daher weiß ich genau und selbstbestimmt was wo ist.

Dann kannst Du doch testweise Bereiche an ne andere Stelle verschieben. 
Du wirst ja nicht den gesamten RAM vollgeknallt haben.
Laß aber an der Originalstelle eine entsprechende Lücke. Wenn Du alles 
gegeneinander verschiebst, wandert alles und Du bist nicht schlauer.

Schwer zu debuggen sind nicht atomare Zugriffe zwischen Main und 
Interrupt. Wenn der Interrupt genau zwischen 2 Bytes zuschlägt, kriegt 
er ein neues und ein altes Byte. Und schon hat er einen Pointer, der in 
den Wald zeigt.
Also lieber zuviel atomar kapseln (CLI, Zugriffe, SEI), als einmal zu 
wenig.

Anton schrieb:
> An und für sich habe ich keinen konkreten Anlass an der Hardware zu
> zweifeln

Stimmt. Zu 99,99% sitzt der Fehler vor dem Bildschirm.

Elektrolurch schrieb:
> Funktionieren denn die Data-Breakpoints bei den AVRs?

Habe ich schon vor Jahren mit dem GDB genutzt, als irgendwelche Studios 
das noch lange nicht konnten.

> Die müssen doch vom Prozessor unterstützt werden.

Ja, klar. Also: beim GDB nicht notwendigerweise, allerdings wird er 
grottenlahm, wenn er das in Software emulieren muss. Dann wird nämlich 
Einzelschritt gearbeitet und jedesmal die Speicherstelle gelesen.

> Selbst bei den XMegas hat das, so weit ich weis - nicht funktioniert.

Bei Xmegas kenne ich mich gerade nicht aus, aber da das schon bei den 
alten Megas funktionierte, würde es mich wundern, wenn sie es dort 
kaputt gemacht hätten.

> Wie sieht das bei den SAMs aus?

Funktioniert auch.

Ein Unterschied zu Code-Breakpoints ist natürlich, dass ein Data 
Breakpoint (GDB nennt das "watchpoint") erst dann triggert, wenn die 
Daten auch geändert worden sind. Ein Code-Breakpoint triggert vor der 
Ausführung des Befehls.

Anton schrieb:
> Momentan
> hoffe ich hier aber noch drauf ob mir jemand funktionierende
> Daten-Breakpoints für AVRxxDx bestätigen kann...

Was spricht gegen einfach ausprobieren?

Oliver

welche Speicherzelle ist das ein Register oder ist das im SRAM. Laß dir 
im Simulator das SRAM (in Memory1-Fenster) anzeigen, wenn das während 
der Programmausführung immer voller wird, dann fehlt wahrscheinlich in 
deinen Programm irgendwo ein ret, reti oder pop. Also entweder beendest 
du ein Unterprogramm nicht das mit dem abspeichern einer 
Rücksprungadresse angesprungen wird, du beendest einen Interrupt nicht, 
welcher ebenfall eine Rücksprungsdresse ablegt oder du pusht aus den 
eben genannten Gründen mehr als du popst.

Anton schrieb:
> Der Datenempfang im Interrupt initialisiert gleichzeitig die
> Interrupt-Ausgabe aufs Display. Das gesamte Handling spielt sich in
> Interrupts ab

Das klingt sehr gefährlich. Hast Du bedacht, das Interfaces nicht 
reentrant sind, d.h. das Main darf keine weitere Instanz aufmachen.

Ich mache für die UART immer 2 FIFO Interrupts und das Main kümmert sich 
um das Parsen und die Ausgabe.

Anton schrieb:
> Nichts Oliver. Sobald möglich.

Arbeitest Du möglicherweise mit AVR Studio 4.x?

wenn das mit dem Simulator nicht so praktisch ist, da man keinen 
Debugger hat. Kannst du in deine Main auch irgendwo einbauen das ein 
Speicherzelle im RAM ausgelesen wird die 00 bzw. FF sein sollte und wenn 
das abweicht, weil die Speicherzelle erreicht wurde kann du einen LED 
einschalten, damit du weist, dass dein SRAM zu Neige geht.

Anton schrieb:
> zumal die seriellen Daten über Funk reinkommen

Also brauchst Du erstmal ein ordentliches Protokoll mit CRC, um die 
Störungen rauszufiltern.

Anton schrieb:
> Nur unter bestimmten, eingrenzbaren Bedingungen, die
> bestimmtem seriellen Input zur Folge haben kommt es zum Fehler.

Klingt dann doch sehr nach einem Problem mit dem Protokoll und einem 
Pufferüberlauf.
Die Entwicklung eines fehlertoleranten Protokolls ist keine einfache 
Sache. Die Protokollstacks in Industriesteuerungen über RS-485 sind oft 
sehr aufwendig und belegen viel Flash.

Da es um Assembler geht, ist’s letztendlich eh egal.

Oliver

es gibt im AVR-Studio einen Watch Funktion habe damit noch nicht 
gearbeiten, glaube das müsste aber für eine Überwachung sein wie du es 
wünscht.

Thomas O. schrieb:
> es gibt im AVR-Studio einen Watch Funktion
Das Watch-Fenster wird nur aktualisiert, wenn du auf einem Breakpoint 
stehst.

Und dass du auf einen Breakpoint kommst, dafür brauchst du den besagten 
Data Breakpoint, der als spezielle Debug-Hardware im Controller 
eingebaut ist und in jedem Maschinenzyklus die Pointerregister X 
und/oder Y und/oder Z mit der gewünschten Speicheradresse vergleicht und 
dann beim Schreiben und/oder Lesen triggert.

Lothar M. schrieb:
> Thomas O. schrieb:
>> es gibt im AVR-Studio einen Watch Funktion
> Das Watch-Fenster wird nur aktualisiert, wenn du auf einem Breakpoint
> stehst.

Das ist die Begriffsverwirrung zwischen GDB, der diese Art von 
Datenüberwachung (egal ob in Hard- oder Software) schon immer 
"watchpoint" genannt hat und den IDEs, die Variablen/Speicherstellen 
gern "watchen".

Nach deinen Aussagen habe ich die Befürchtung, dass du in den 
Interrupt-Routinen viel zu viel "machen" läßt. In der Regel macht die IR 
nur das Nötigste, so dass die Main-Routine weiterkommt. Und bevor du 
jetzt mit irgendwelchen Breakpoints herumhampelst, schreib dir doch ein 
paar schlaue Testroutinen. Du kannst das Assemblerprogramm doch beliebig 
verkleinern und wenn es sein muß jeden "Mist" einzeln testen. Viel Spass 
jedenfalls...Rainer

Anton schrieb:
> Da
> offensichtlich noch niemand damit und den neuen AVRs gearbeitet hat bin
> ich gespannt, was meine eigene Recherche demnächst ergibt.

OK, ich auch...
Rainer

uff

Hätte ich nicht erwartet. Aber damit kann ich auch gerade mit AVaRICE 
nicht dienen, das hängt in dieser Hinsicht viel zu weit hinterher.

Ich verstehe nicht, warum du dich so auf diese Breakpoints versteifst. 
Du hättest doch schon längst eine schlaue Testroutine in dein Programm 
einbauen können! Etwa so, ich nummeriere meine Unterprogramme durch und 
schreibe nach jedem Programmaufruf die Nummer weg und vergleiche den 
Inhalt des Speicherbereichs vorher/nachher. Dann hab ich schon mal den 
Punkt im Programm wo was passiert. Dann kann man weitersehen...
Rainer

Rainer V. schrieb:
> Ich verstehe nicht, warum du dich so auf diese Breakpoints versteifst.

Weil sie für selten und von außen getriggerte Ereignisse, die man 
schlecht simulieren kann, die sinnvollste Methode sind?

Die Hersteller bauen die entsprechende Logik nicht umsonst da rein.

Jörg W. schrieb:
> Die Hersteller bauen die entsprechende Logik nicht umsonst da rein.

Ja, ist schon klar...sein Controller kann das aber nu mal nicht...

Anton schrieb:
> Dazu kommt im Moment ein ganz anderes "Problem": Den Fehler überhaupt zu
> provozieren. Da wird noch eine Menge Geduld nötig sein.

Ja, sorry, du hast ja recht. Aber wenn es keine Debugging-Möglichkeit 
gibt, dann ist halt das Elend groß. Natürlich kann ich großspurig 
"schlau" schreiben, aber machen muß ichs ja nicht...ich wünsche 
jedenfalls einen Erfolg!
Gruß Rainer

um zu überprüfen ob der Stack voll läuft kann man doch in der 
Haputschleife einfach nachsehen ob etwas am Anfang des SRAM geändert 
wurde.

Der sieht ja normal so aus, geht z.B: von $0060-00DF und wird von unten 
her beschrieben. Jetzt schau man halt ab und zu nach ob $0070 verändert 
wurde und erkennt eine Hoche Stackbelastung was auf einen baldigen 
Überlauf hinweist.
Wenn das also sein kann muss man schauen was man alles anspringt und 
nicht wieder zurückspringt. Hier müsste man dann eben schauen ob jeder 
Interrupt mit reti und jeder Aufruf(rcall) eines Unterprogramms auch mit 
ret beendet wird. Das kann man normal selbst im Simulator mit ein paar 
Breakspoints finden wenn man an und ab mal die Interrupts auslöst, man 
braucht ja nur das Feld für den Interrupt zu setzen und schon verzweigt 
er nach ein paar Takten. Wenn du so ein Unterprogramm nicht mehr verläßt 
dann arbeite leiber mit jmp/rjmp anstatt mit call/rcall.

1

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

2

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

3

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

4

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

5

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

6

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

7

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

8

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

9

FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10 33 55 77

10

...

rbx schrieb:
> Naja, vorher kommt noch die spannende Frage, wie gut kommst du
> eigentlich mit Linux, dem GDB

Hilft aber an der Stelle nix. AVaRICE kann mit diesen Chips noch nicht 
umgehen.

Wenn es das Atmel Studio nicht kann, dann hilft das nicht viel, selbst 
falls die Hardware es eigentlich könnte.

Anton schrieb:
> Ich möchte doch nur den kurzen Moment
> aufklären an dem etwas falsches an besagten Speicher geschrieben wird
> und dann den verusachenden Code samt seiner Eingangsdaten untersuchen.

Die Betonung liegt wohl auf "nur" und gleichzeitig erzählst du von 
absolut sporadischen Fehlern. So wie Stefan vorschlägt, könnte das was 
werden. Das "sporadisch" zwingt dich geradezu, den ganzen Verkehr zu 
protokollieren. Aber vielleicht fällt dir ja doch was besseres 
(schnelleres!) ein...
Rainer

Rainer V. schrieb:
> Das "sporadisch" zwingt dich geradezu, den ganzen Verkehr zu
> protokollieren.

Nur, wenn man es versuchen will, per Simulation nachzustellen. Dann wäre 
das ja die einzige Möglichkeit, um die externen Ereignisse in exakt 
gleicher Form reproduzieren zu können.

Nichtsdestrotz hat das Einfügen von Debug-Code oft genug 
Timing-Änderungen zur Folge, die u.U. das Problem dann auch gleich mal 
komplett maskieren können. Es ist dann nicht weg (das ist die Gefahr), 
tritt aber durch das geänderte Timing vielleicht viel seltener auf.

Ich kann mir immer noch nicht vorstellen, dass die Hardware dieser AVRs 
das nicht können sollte, habe aber gerade keine Zeit, mir das selbst 
anzusehen.

Anton schrieb:
> Du kannst ein Programm im Gegenteil auch nur aus Interrupts aufbauen
Huh, diese Art von Programmen sind aus Erfahrung unbeherrschbar. Einmal 
am Tag, in der Woche, Monat, Jahr tickt so ein Ding aus oder frisst sich 
dank Prioritätsinversion fest. Kann sein, dass man das nicht merkt, aber 
es passiert.

> Die Interrupts werden round robin nacheinander abgearbeitet wenn
> jeweils fertig.
Eben das ist nicht das Konzept von Interrupts. Sie werden bestenfalls in 
deinem Gedankenmodell aber niemals in der realität "zyklisch der Reihe 
nach" (= ROUND robin) abgearbeitet. Sondern eben immer dann, wenn sie 
dank ihrer Priorität und freier Rechenleistung drankommen. Und wenn ein 
externer Signalgeber mit hoher Prio austickt, dann kommt dieser 
Interrupt laufend. Bei uns war das z.B. ein Drehgeber in einer 
ausgeleierten Maschine, der halt wie blöd hin- und herzappelte. So einen 
Fehler hast du in der Firma nie, weil da nur neue Maschinen herumstehen.

Mein ideales µC-Programm ist eine Hauptschleife, die in <1ms durchläuft 
und dabei alles macht (ggfs. müssen längere Rechnungen halt in mehrere 
Zyklen aufgeteilt werden). Und die kurzen ISR speisen nur neue 
Informationen in diese Mainloop ein.
Ein Supervisor (das ist ein besserer Dreizeiler, der einen Hardwaretimer 
mit dem vorigen Timerstand vergleicht) überwacht die Laufzeit der 
Mainloop und gibt Alarm, wenn die mal stark nach oben ausreißt.

Rainer V. schrieb:
> Ich verstehe nicht, warum du dich so auf diese Breakpoints versteifst.
Wer in seinem Prozessor mal tatsächlich die Hardware für echte Data 
Breakpoints hatte (wenigstens für einen einzigen), der wird sie 
bitterlich vermissen, wenn er ein Problem wie das hier zu knacken hat.

Und wirklich elegant wird es, wenn diese Hardware es hergibt, nur dann 
den Breakpoint zu triggern, wenn genau ein bestimmter Wert an eine 
bestimmte Adresse geschrieben wird:
https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Setting-multiple-breakpoints-and-a-program-trace-on-MCF5216-V2/m-p/274479


Zurück zum Thema:
Anton schrieb:
> Ich möchte doch nur den kurzen Moment aufklären
> an dem etwas falsches an besagten Speicher geschrieben wird
Gibts nich weil is nich.

Du musst also wegkommen vom "kurzen Moment" hin zu statistischen 
Methoden: wenn das immmer die selben korrupten 28 Adressen sind, musst 
du dort eine Regelmäßigkeit finden.
Du musst dir also etwa solche Fragen ausdenken und die antworten darauf 
finden:
Welche Abstände haben die korrupten Bytes? Sind die einezeln, gepaart 
oder sonstige Cluster? steht immer der selbe Müll drin?  Wann passiert 
"es"? Passiert "es" immer an allen Speicherzellen gleichzeitig? Passiert 
"es" bei vielen Geräten gleich häufig? Passiert "es" auch, wenn an du 
bestimmte Hardwarekomponenten nichts anschließt, also bestimmte 
Interruptquellen nicht verwendest?

MaNi schrieb:
> eine statische Code Analyse
Gibts da auch Tools für AVR-Assemblercode?

Anton schrieb:
> Das wär viel hier zu grobkörnig. Ich möchte doch nur den kurzen Moment
> aufklären an dem etwas falsches an besagten Speicher geschrieben wird
> und dann den verusachenden Code samt seiner Eingangsdaten untersuchen.

Tja, und ohne Databreakpoint geht das halt nur über eine ausführliche 
Codeanalyse. Und weil du das für das ganze Programm nicht sinnvoll 
machen kannst, musst du den Fehlerpunkt einkreisen. Dazu hilft alles, 
was dir dabei hilft. Wenn logging dann am veränderten Timing scheitert, 
ist dein ganzes Konzept Murks. Murks wegen zu großer Komplexität.
So furchtbar kompliziert klingt die Aufgabenstellung ja jetzt nicht.

Was ich bei deiner ganzen Geschichte allerdings sehr seltsam finde, ist, 
daß ein Writepointer von den Eingangsdaten abhängen soll, ohne dass du 
sagen kannst, wie, wo, und warum. Das kann doch eigentlich nicht sein.
Wenn’s nur ein klassischer Bufferüberlauf wäre, könntest (oder müsstest) 
du einfach JEDEN Bufferzugriff gegen Überlauf absichern.

Oliver

Lothar M. schrieb:
> Anton schrieb:
>> Du kannst ein Programm im Gegenteil auch nur aus Interrupts aufbauen
> Huh, diese Art von Programmen sind aus Erfahrung unbeherrschbar.

Ist auch meine Erfahrung. Man bestiehlt sich nur unnötig um einen 
Ausführungslevel, der vieles einfacher macht.
Die zu große Komplexität Deines Programms ist also selbst verschuldet.

Bei den neuen AVRs kann man zwar round robin einstellen, statt fester 
Priorität, aber das macht alles nur noch unvorhersehbarer. Man hat ein 
völlig unterschiedliches Verhalten bei normaler und bei hoher 
Interruptlast.

Einer Mainloop ist dagegen die Interruptlast völlig schnurz. Sie 
arbeitet alles immer in der gleichen, von Dir bestimmten Reihenfolge ab 
und damit gibt es auch kein Chaos und keine Komplexität.
Das Schlimmste, was passieren kann, eine serielle FIFO läuft voll und 
schmeißt die überzähligen Bytes weg. Durch ein Protokoll mit 
Paketnummernzähler läßt sich das erkennen und die verlorenen Pakete 
können nochmal angefordert werden. Oder man erzeugt erstmal nur ne 
Fehlermeldung, daß was im Argen liegt.

Anton schrieb:
> Der SRAM-Speicher ist bei weitem nicht ausgelastet.

Warum machst Du dann nicht, was ich bereits vorgeschlagen hatte?
Die Daten der einzelnen Funktionen in freie Bereiche zu verschieben und 
dann beobachten, bei welcher Funktion die ungewollten Änderungen mit 
wandern.

EAF schrieb:
> Die beiden Schreibweisen sind äquivalent.

Rein formal schon.
Nur speziell auf einem 8Bitter macht ein Index vieles einfacher. Ist das 
Array <256 Byte, reicht ein Byte als Index und ich muß nichts atomar 
kapseln. Auch kann ich den Index einfach auf Überlauf testen (mit sizeof 
vergleichen), unterlaufen kann er ja nicht.

Stefan ⛄ F. schrieb:
> Das wird sowieso nötig sein, um den Erfolg der Korrektur zu belegen.

In deiner Umgebung offenbar, an anderen Stellen wird es auch genügen, 
wenn man beim Debuggen die Ursache des Fehlers sauber erkennen konnte.

Jörg W. schrieb:
> Die Hersteller bauen die entsprechende Logik nicht umsonst da rein.

In manchen Fällen macht es Sinn Fehlerstatisiken in eine "fertige" 
Software einzubauen um bei Kunden laufende Software auf Qualität zu 
überprüfen. Manche Fehler treten sehr selten auf und sind im Labor nicht 
zu erfassen, daher ist das Erfassen von Exeptions (z.B. Division durch 
Null) und deren Speicherung sinnvoll.

Anton schrieb:
> Was die Abwesenheit der Data Breakpoints bei den AVRs erklären könnte
> wäre evt. die verminderte Leistungsfähigkeit von UPDI (nur eine Leitung,
> bei PDI zwei).

Eigentlich nicht. debugWIRE ist auch ein Eindrahtprotokoll. Gut, die 
haben tatsächlich keine data breakpoints, aber das lag daran, dass sie 
gar keine separate Debug-Hardware in den MCUs vorgesehen hatten. 
debugWIRE war schlicht ein Monitor-ROM, also sowas, wie man schon vor 
30+ Jahren seine Mikroprozessoren debuggen konnte. Code-Breakpoints 
wurden dort durch Umflashen der jeweiligen Page eingefügt. Klingt 
gruselig, dafür hat es wiederum gar nicht so schlecht funktioniert.

Ansonsten verursachen data breakpoints ja (im Gegensatz bspw. zu trace 
data beim ARM) nicht per se mehr Traffic auf der Debug-Schnittstelle.

Peter D. schrieb:
> EAF schrieb:
>> Die beiden Schreibweisen sind äquivalent.
> Rein formal schon.
Aber in der Praxis sieht das schon spannender aus. Wenn da steht:

erg = *ptr+i*3;

Dann stellt sich die Frage, ob das so sein muss, oder ob das der Grund 
für den Fehler ist, den der Kollege gestern kurz vor Feierabend noch 
eingebaut hat, obwohl er eigentlich sowas wollte:

erg = *(ptr+i*3);

So ist das eindeutig:

erg = ptr[0]+i*3;

Statt:

erg = ptr[i+3];

Ich arbeit auch mit Logs. Ein kWord als Buffer, wo man periodisch was 
reinschreibt und per Protokol ausliest.
Wenn die Vermutung, die Kommunikation sei zustaenig in der luft liegt, 
wuerd ich fehlerhafte Kommunikation einspeisen. Erst mal den 
Kommunikationsbuffer erhoehen. Und dann immer laengere Meldungen senden. 
Bis ans zulaessige Maximum.

Die Meldungen enthalten die Laenge selbst ?
Wie lang darf eine Meldung sein ?
Wird das ueberprueft ?
Was geschieht in diesem Fall, wo die Laenge in der Meldung als zu lange 
angegeben wird ?
Wird die Meldung als Block oder byte fuer byte, dh Zustandmaschine, 
verarbeitet ?

Anton schrieb:
> Immer dasselbe, 28 Bytes, an derselben Stelle wild und quer über zwei
> von mehreren Datenpuffern (deren Zeiger hintereinander an die
> Senderoutine übergeben werden).

Bei 28 Bytes sollte doch eigentlich herauszukriegen sein, welche Task 
diese erzeugt hat.

Anton schrieb:
> Nachdem in einem Teil des Hauptprogramms dessen vielverwendetes Register
> R16 wie von Zauberhand zuweilen einen unerklärlichen Wert bekam...

Ja, das ist ein Problem von Assembler, man ist für die Registerrettung 
selber zuständig.
Ich hab ~10 Jahre Assembler benutzt, ich weiß also ganz genau, warum ich 
auf keinen Fall dahin zurück will. Ich weiß auch, daß der Wechsel schwer 
fällt.

In C übernimmt alle Variablenverwaltung der Compiler und der kann das 
viel besser als ein Mensch. Z.B. die Overlaytechnik beherrscht er 
perfekt, d.h. Nutzung des selben Registers für verschiedene lokale 
Variablen. Damit kann man sich in Assembler leicht ein Bein stellen.

Jörg W. schrieb:
> Habe ich schon vor Jahren mit dem GDB genutzt, als irgendwelche Studios
> das noch lange nicht konnten.

Das finde ich jetzt hochinteressant! Unterstützt der GDB immer 
Data-Breakpoints? Sprich: Könnte ich mit dem GDB in der Konsole bei 
jedem Debug-Adapter diese Breakpoints verwenden?

Das wäre mal der Ausschlag, sich mit der GDB-Konsole 
auseinanderzusetzen. Letzte Jahr habe ich mal mit großer Verzweiflung 
danach gesucht, welches Ereignis einen Wert in einem Register gesetzt 
hat.

Anton schrieb:
> Gutes Programmieren kann aber, insbesondere wenn die
> Produktivität (im Hobby) nicht an Nummer 1 steht, sehr viel mehr sein
> als das bloße Vermeiden von Unachtsamkeiten.

Naja, im Alter wird man bequemer und behält nicht mehr jedes Detail im 
Kopf. Auch hat man noch andere Verpflichtungen und das Hobby bleibt mal 
längere Zeit liegen.
Da ist es dann schön, wenn einem der Compiler viele monotone Arbeiten 
abnimmt und man sich auf die eigentlichen Programmfunktionen und Abläufe 
konzentrieren kann. Man kann dann auch leichter das Programm komplett 
umstellen, wenn man in einer Sackgasse gelandet ist.

Anton schrieb:
> Während der eine die maximale
> Gestaltungsfreiheit bei minimalen Mitteln schätzt

Das kann man aber auch anders sehen. Ich habe unter C mehr Freiheiten, 
etwas zu realisieren, was ich mich in Assembler nicht getraut hätte, 
weil es zu komplex würde. Z.B. meinen Scheduler möchte ich nicht in 
Assembler schreiben, obwohl ich es könnte.

Walter T. schrieb:
> Unterstützt der GDB immer Data-Breakpoints?

Der GDB erst einmal immer, nennt sich "watchpoint".

Inwiefern er es aber in Hardware abbilden (lassen) kann, das braucht 
natürlich entsprechende Unterstützung durch die Hardware selbst. Auf dem 
PC muss dafür das OS die Möglichkeiten der Hardware nach oben reichen 
(habe ich zusammen mit dem Autor von AVRDUDE, Brian Dean, mal vor vielen 
Jahren für FreeBSD gebaut, weil ich in irgendwelchem Tcl/Tk-Code nicht 
anders eine data corruption zu finden in der Lage war), oder aber eben 
bei einem Embedded-Target muss das der entsprechende Adapter zur 
Anbdindung ans Target bieten.

Hat man das nicht, wie beschrieben, gibt's einen Software-Watchpoint. 
Wenn er es in Hardware abbilden kann, wird es beim Einrichten auch als 
"hardware watchpoint" ausgewiesen. Je nach Hardware muss man u.U. mit 
etwas Zeiger-Jongliererei herumopern um den zu überwachenden Bereich in 
eine Größe zu zwängen, die die Hardware unterstützt (meist nur 2^N Bytes 
mit N <= 3 oder so).

Stefan ⛄ F. schrieb:
> Ich empfehle log Meldungen.

Wenn das zu langsam ist, "Meldungen" über Bitmuster an freien GPIO-Pins 
ausgeben und mit dem LA überwachen.

Anton schrieb:
> Ich möchte doch nur den kurzen Moment
> aufklären an dem etwas falsches an besagten Speicher geschrieben wird

Ich habe ein ähnliches Problem in einem Windows-Programm gehabt. Für 
eine Betriebsdatenerfassung senden viele Maschinen ihre Daten, die in 
der Entwicklungsphase zu unerwarteten Fehlern führten. Ein 
Windows-Programm stürzt leider bei nicht abgefangenden Fehlern einfach 
ab.
Zur Analyse habe ich eine "Trace-Datei" geschrieben, die den Weg des 
zyklischen Programms aufzeichnet. Nach jedem Zyklus wird die Datei 
gelöscht. Im Fehlerfall sehe ich dann wie weit das Programm fehlerfrei 
gelaufen ist.
Die Übertragung der Trace-Aufzeichnung auf den AVR hängt von deinen 
Möglichkeiten ab. Als erstes muss die Aufzeichnung im Fehlerfall 
gestoppt werden. So ist der letzte Weg durch alle Interrups 
festgehalten. Je nach Ausgabemöglichkeit kann man den Trace in einen 
intakten RAM-Bereich schreiben oder über eine serielle Schnittstelle 
senden.
Ich sehe meistens einen Menübereich im Display vor, in dem ich 
Analysedaten ausgebe.

Anton schrieb:
> Ich sehe hier höchstens die Möglichkeit einzelne Wegmarken

Genau das meine ich. Damit ist man zuerst grob an der Fehlerstelle. Man 
sieht schon mal die Abfolge der Interrupts. Danach kann man das 
schrittweise verfeinern. Bis man am Schluss (wenn es denn sein muss) am 
kritischen Assemblerbefehl ist.

Anton schrieb:
> In meinem Fall ist mit der richtigen Display-Ausgabe aber
> bereits die beste Rückmeldung vorhanden

Das verstehe ich nicht. Die beste Rückmeldung kann es nicht sein, sonst 
hättes du die Fehlerstelle. Wichtig ist natürlich vor jedem 
Trace-Eintrag den korrupten RAM-Bereich zu prüfen und im Fehlerfall die 
Aufzeichnung zu stoppen, damit sicher ist, das bis zum letzten Trace 
alles ok ist.

Anton schrieb:
> dort den Status zu loggen
?? nichts loggen
Ich meine das so:
-RAM prüfen
-wenn korrupt, Trace stoppen (Stop=1)
-wenn Stop=0 Trace schreiben

Das jeweils erst an groben Wegmarken, dann an der kritischen Stelle 
immer feiner. Der Trace endet dann an vor der kritischen Stelle.

Anton schrieb:
> Wenn viele Einflüsse von außen hinzukommen von dem
> Programmzweige und Datenzugriffe abhängen bliebe eigentlich nichts
> anderes übrig als zu versuchen, dieses Gesamt-System zu "loggen".

War mein Vorschlag schon vor einiger Zeit. Trotzdem kannst du ja auch 
versuchen, sinnvolle Teilprogramme zu "isolieren". Das es einfach gehen 
sollte, hat ja keiner gesagt :-)
Gruß Rainer

Anton schrieb:
> Wenn es diesen einen Befehl aber gar nicht gibt?

Dann ist es eben kein Programmfehler. Wenn es denn bei der 
Registerrettung passiert, dann siehst du ja, dass zu Beginn der 
Interruptroutine der Fehler da ist und du weißt, die Registerrettung 
geht schief. Dann ist also der Stack nicht richtig dimensioniert.

Anton schrieb:
> Im Grunde wäre dafür der zulässige Wertebereich jeder RAM-Zelle zu
> prüfen

Kennst du nicht wenigstens den Bereich im RAM, der überschrieben wird? 
Dann könntest du den Bereich durch verschieben deiner Variablen frei 
halten und dann einfach prüfen, ob was geschrieben wird. Du musst 
irgendwie den Fehler erkennen, sonst geht die Methode nicht.

eigentlich sollte man wissen welche Register eine Interruptroutine 
verwendet, dann pushed und popt man eben nur diese. Ich nehme mir in der 
Interruptroutine soviel Zeit und lege die Ergebnisse an eine feste 
Stelle im SRAM ab um nicht unnötig Register dafür zu benutzen die ich 
später wiederum pushen/poppen muss. Klar wenn man sich unsicher ist kann 
man alle 32 Register auf den Stack legen und später wieder herstellen. 
Deaktiviertst du die Intterupts wärend du in einer Interruptroutine 
bist? Wenn nicht funkt dir vielleicht ein anderer Interrupt dazwischen.

Ich würde auch schauen, das Programm so zu gestallten, dass ein paar 
Statusmeldungen ausgegeben werden, wie schon jemand empfohlen hat. z.B. 
einen Zahler wie oft ein Interrupt schon aufgetreten ist. Oder sogar 
über einige Pins das Auswählbar zu machen also mit einem kleinen DIP 
Schalter vorzugeben was du sehen möchtest.

Anton schrieb:
> Da hat man schon modernste AVRs

Nun ja, habe mir die Datenblätter gerade mal angesehen.

UPDI stammt von der vorhergehenden Tiny-Familie (Tiny817 etc.). Tinys 
sollen billig sein und dafür macht man den Chip halt klein. Da werden 
dann eben auch mal Features "abgespeckt", und so sind für UPDI nur noch 
zwei Hardware-Breakpoints beschrieben statt früher (beim JTAG der 
klassischen Megas und beim PDI der Xmegas) vier. Für einen data 
breakpoint muss man jedoch stets ein Paar Breakpoint-Register benutzen 
bei der AVR-Architektur (eins für die Adresse, das zweite für die 
Länge). Damit ist klar, dass mit den zwei Breakpoint-Registern des UPDI 
keine data breakpoints gehen.

Warum man nun für die dann wieder "Mega" genannte Weiterentwicklung bei 
den Limitierungen geblieben ist, werden dir nur Insider verraten können. 
Vermutung: so ließ sich durch Weiterbenutzung existierender 
Hardwareblöcke Entwicklungszeit sparen, auch die existierenden Tests 
lassen sich 1:1 weiter verwenden, genauso die Softwareblöcke im Debugger 
des Studios. "Time to market" ist in der Halbleiterei ohnehin schon 
immer eine gefühlte Ewigkeit (allein ein Fab-Durchlauf dauert oft schon 
ein Vierteljahr), ein paar eingesparte Wochen können da schon relevant 
sein und der Grund, auf ein paar seltener genutzte Features zu 
verzichten.

Ähnliche "als Mega getarnte Tinys" gab es auch schon zuvor: ATmega88 & 
Verwandte. Auch die haben beispielsweise kein JTAG bekommen sondern nur 
debugWIRE. Da sie aber andererseits die Multiplikationsbefehle der Megas 
bekommen haben, hat man sie wohl auch "Mega" nennen wollen.

Bliebe für den aktuellen Fall noch die Frage, ob man den gleichen Code 
auch auf älteren, "klassischen" Megas oder Xmegas laufen lassen könnte, 
auf denen man die nötige Hardwareunterstützung hat.

Anton schrieb:
> wurde bei seinem zentralen "nur 1 Leitung" Vorteil aber dennoch von den
> billigeren Tinys übernommen.

Das muss keineswegs der einzige Vorteil sein. Dazu müsste man sich die 
Entscheidungsträger anhören …

Anton schrieb:
> Mit einem Mindestmaß an Übersicht sollte das bei den paar Registern
> nicht passieren. So einen blöden Fehler hat man nur einmal, dann ist man
> geheilt ;-)

Aus Erfahrung kann ich sagen, solche Fehler passieren immer wieder.
Man müßte sich ein Tool schreiben, was solche Fehler aufdecken hilft. 
Einen schönen Fehler hatte ich mal, indem ich die Push/Pop Reihenfolge 
vertauschte, d.h. 2 Register waren nach dem Interrupt vertauscht. Da 
grübelt man auch ewig.

Die Fehlermöglichkeiten in Assembler sind also ungleich höher, als in C.
Es passiert schon mal, daß ein Compiler Fehler macht. Aber der Vorteil 
ist, daß Millionen Leute ihn benutzen und solche Fehler schnell 
auffallen. Ich meine, auch der WINAVR hatte mal einen Registerfehler.

Anton schrieb:
> welche Möglichkeiten gibt es beim AVR-Debugging, eine konkrete
> Speicherstelle zu überwachen und beim Schreiben dorthin mit einem Halt
> abzubrechen damit man ermitteln kann welcher Code dazu führte?

Vielleicht so:

Am Anfang als erstes und am Ende (vor reti) aus jedem Interrupt eine 
kleine Routine aufrufen. (rcall check_Speicherstelle). Hat sich der 
Inhalt geändert, Rücksprungadresse von Stack holen, anzeigen (LCD) und 
stop.
Damit würdest du zumindest die Stelle bekommen, wo die Änderung 
detektiert wurde. Ist das vorne beim Interrupt, dann hat das 
Hauptprogramm die Speicherstelle geändert. Wurde das vor reti entdeckt, 
dann hat die Interruptroutine reingeschrieben. Damit könnte man den 
Fehler wenigstens eingrenzen und dort weiter suchen. Wäre das ein Weg?

Anton schrieb:
> Jenes nicht gesicherte
> R16

Du wolltest maximale Freiheit, du hast sie bekommen.

Oliver

Anton schrieb:
> So schauts aus. Über die Kehrseite einer schönen Medaille darf man sich
> nicht beschweren.

Immerhin konntest du zumindest die Fehlerursache finden. Die 
Auswirkungen sind natürlich verhehrend und durch einfaches 
"Rückschließen" wohl kaum aufzuspüren. Es hätte aber auch ein 
sporadischer, wirklich ekliger Fehler ala Störungen auf irgendwelchen 
Pins oder gar auf der Versorgungsspannung sein können! Deshalb kann man 
wohl mit Recht sagen, is noch immer joot gejangen :-)
Gruß Rainer

Anton schrieb:
> Vor dem Problem stünden dann alle Programmiersprachen

Ja klar...genau genommen jeder beliebiger Controller...Ich hatte gerade 
nur im Sinn: ekliger Programmierfehler gegen eklige Hardwareprobleme...
Gruß Rainer