Ich komme zu Euch mit einer Frage da ich mir momentan nicht selber weiter zu helfen vemag. Bitte lasst mich wissen ob ich die Quellen posten soll. Das Problem und Hintergrund: Ein von mir erstelltes Program für einen 1284P MCU welches als Einzelquell Datei im Arduino IDE einwandfrei funktioniert zeigt nach Umsetzung in ein modulares Programm mit zahlreichen Modulen nun ein sonderbares Verhalten mit statischen Variablen innerhalb ein paar Funktionen. Dieses Programm verwendet nur die Arduino EEPROM und Serial Libraries. Sonst ist es als so weit wie möglich als konventionell geschriebenes Program ausgeführt. Ich verwende sonst keine Arduino bezogene Anweisungen. Alle Hardware bezogenen Register Zugriffe sind in konventioneller Art ausgeführt. Mir ist ein Vetsagen von statischen Variablen noch nie vorgekommen. Die Probleme traten in einer TIMER ISR und ADC ISR von mir auf und eine normale aufgerufene Funktion. Allen diesen Routinen ist gemeinsam, dass statische Variablen vorhanden sind. Die Statischen Zählervariablen zählen nicht richtig und statische boolean Flags haben Werte zwischen 0, 1, und 2. Sonst verhalten sich alle anderen Programm Funktionen richtig. Das komische ist, so bald ich die beiden Funktionen wieder in das Hauptprogram (.INO) zurück verfrachte, funktionieren alles wieder wie vorher einwandfrei. Statische variablen als volatile globale zu deklarieren hat auch nicht geholfen. Es gibt absolut keine Compiler Warnungen oder Fehler. die extra Programm Dateien von mir sind alle als ".cpp oder .h" ausgeführt. Nun nehme ich vorerst nicht an, dass hier ein echter GCC Kompiler Fehler vorliegt. Eher vermute ich, dass irgendeine vom Arduino IDE gesetzte ungünstige Kompiler Flag oder Einstellung vielleicht das Problem irgendwie verursacht. Es ist auch möglich, dass Arduino Für mich ungünstige nicht ersichtliche Konfigurierungen vornimmt. Dieses Problem ist mir im Augenblick noch zu schwierig da ich die Feinheiten vom GCC Kompiler leider nicht im Griff habe. Ich habe die Kommandoline modifiziert um einen Map File zu erhalten. Aber da muss ich mich erst mal durch arbeiten. Gibt es eine Symbol Table Datei wo die Adresse jeder Variablen gelistet ist? Was meint Ihr dazu? Hoffnungsloser Fall? Soll ich das ganze Programm hier posten? Aufgeben? Das Problem für mich liegt speziell auch in der Notwendigkeit, das Arduino IDE zur Wartung und Entwicklung benützen zu können, weil dies ein Open Source HW/SW Datenlogger Projekt sein soll. Für mich selber würde ich mit CodevisionAVR oder unabhängigen GCC-AVR arbeiten und hätte dieses spezifische Problem schon von vornherein nicht. Ein sehr ähnliches Program funtioniert unter CV-AVR als modulares Programm sowieso einwandfrei. Aber diese Lösung verfehlt den Zweck dieses Projektes. Dieses Programm hat in ähnlicher Form ohne wesentliche Änderungen übrigens auch unter einigen PIC Familien(16/18/24/30/33), AVR, STM32, Z8, und 8051 immer einwandfrei funktioniert. Zur Zeit habe ich leider AVR-GCC (noch) nicht als unabhängige Tool Chain installiert und müsste mir auch einen Makefile zusammenzustricken. Ich bin Euch für jede Hilfe oder Denkanstoß recht dankbar. vielleicht ist die Lösung des Problems nachher sogar so einfach und offensichtlich dass ich mich danach schämen muß um nicht selber darauf gekommen zu sein. Zur Zeit habe ich leider noch große Balken vor dem Kopf. Mfg, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Gibt es eine Symbol Table Datei wo die Adresse jeder Variablen gelistet > ist? avr-nm <name der ELF-Datei>
Jörg W. schrieb: > Gerhard O. schrieb: >> Gibt es eine Symbol Table Datei wo die Adresse jeder Variablen gelistet >> ist? > > avr-nm <name der ELF-Datei> Danke, Joerg! Werde das gleich anpacken. Gruss, Gerhard
Jörg W. schrieb: > Gerhard O. schrieb: >> Gibt es eine Symbol Table Datei wo die Adresse jeder Variablen gelistet >> ist? > > avr-nm <name der ELF-Datei> Hallo Joerg, hat funktioniert. Leider zeigen beide Programm Versionen keinen Unterschied außer einer geringfügiger Verschiebung der Variablen Adressen. Es sind alle der Problem statischen Variablen richtig nach Typ aufgelistet. Trotzdem bin ich jetzt ein bischen weiter. Gerhard
Gerhard O. schrieb: > Eher vermute ich, dass irgendeine vom Arduino IDE gesetzte > ungünstige Kompiler Flag oder Einstellung vielleicht das Problem > irgendwie verursacht. Es ist auch möglich, dass Arduino Für mich > ungünstige nicht ersichtliche Konfigurierungen vornimmt. Viel wahrscheinlicher ist es, dass das Problem in deinem Programm zu suchen ist, z.B. ein Schreiben über das Ende eines Arrays hinaus. Im (scheinbar) funktionierenden Fall wird dabei halt einfach nichts lebenswichtiges getroffen.
Stefan E. schrieb: > Viel wahrscheinlicher ist es, dass das Problem in deinem Programm zu > suchen ist, z.B. ein Schreiben über das Ende eines Arrays hinaus. Yep, sowas wäre jetzt auch meine nächste Idee gewesen.
Jörg W. schrieb: > Stefan E. schrieb: >> Viel wahrscheinlicher ist es, dass das Problem in deinem Programm zu >> suchen ist, z.B. ein Schreiben über das Ende eines Arrays hinaus. > > Yep, sowas wäre jetzt auch meine nächste Idee gewesen. Hallo Stephan und Joerg, Danke für den Hinweis, werde in dieser Richtung recherchieren. Die in Frage kommenden Funktionen verwenden in der Tat Arrays;-) Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Jörg W. schrieb: >> Stefan E. schrieb: >>> Viel wahrscheinlicher ist es, dass das Problem in deinem Programm zu >>> suchen ist, z.B. ein Schreiben über das Ende eines Arrays hinaus. >> >> Yep, sowas wäre jetzt auch meine nächste Idee gewesen. > > Hallo Stephan und Joerg, > > Danke für den Hinweis, werde in dieser Richtung recherchieren. > > Die in Frage kommenden Funktionen verwenden in der Tat Arrays;-) > > Gerhard Wenn ich die (globalen) Arrays als erstes deklariere und dann erst die paar anderen globalen variablen, dann funktioniert das Programm wieder richtig. Gegen Array Überschreitungen hatte ich entsprechenden Schutz Code eingebaut. Sobald ich den alten Zustand wieder herstelle, habe ich wieder die alten Probleme. Ganz klar ist mir im Augenblick nicht was hier vor sich geht. Man muesste das mal mit dem Debugger untersuchen. Was mir auffällt ist, daß die Adreßbereiche der Arrays nicht aneinander gegliedert zu scheinen. Beim PIC Compiler waren in der Symbol Tabelle Arrays immer genau nach Groesse aneinander gereiht. Vorerst vielen Dank, Gerhard
>Wenn ich die (globalen) Arrays als erstes deklariere und dann erst die >paar anderen globalen variablen, dann funktioniert das Programm wieder >richtig. Gegen Array Überschreitungen hatte ich entsprechenden Schutz >Code eingebaut. Das klingt ziemlich nach einem Pointerüberlauf. Du könntest zum Test Deine Arrays ein wenig größer als benötigt machen. An die AVR-GCC Experten: Wie ist es mit einen Stack-Überlauf? Wie groß ist eigentlich der Stack und wo liegt er?
chris_ schrieb: >>Wenn ich die (globalen) Arrays als erstes deklariere und dann erst die >>paar anderen globalen variablen, dann funktioniert das Programm wieder >>richtig. Gegen Array Überschreitungen hatte ich entsprechenden Schutz >>Code eingebaut. > > Das klingt ziemlich nach einem Pointerüberlauf. > Du könntest zum Test Deine Arrays ein wenig größer als benötigt machen. Danke für den Hinweis. Werde ein paar Versuche in dieser Richtung unternehmen. Nachtrag: Habe den Nichtsnutz gerade überführt: Das 16-bit Resultat Array für die ADC ISR Ausgabe hat einen Array Ueberlauf produziert. Ich hatte da in der Tat einen Gerhard-BUG(!) welche einen Array Überlauf (n+1) verursacht hatte. Nach Behebung lässt sich das Programm nun jetzt durch nichts mehr stören. Saß der Übeltäter doch tatsächlich vor dem Computer... Gerhard > > An die AVR-GCC Experten: Wie ist es mit einen Stack-Überlauf? Wie groß > ist eigentlich der Stack und wo liegt er?
:
Bearbeitet durch User
chris_ schrieb: > An die AVR-GCC Experten: Wie ist es mit einen Stack-Überlauf? Unwahrscheinlich. > Wie groß > ist eigentlich der Stack und wo liegt er? By default werden die Daten von unten nach oben im SRAM abgelegt, der Stack vom Ende nach unten. Solange der SRAM nicht schon zu 98 % mit statischen/globalen Daten gefüllt ist, läuft der Stack da normalerweise nicht rein. Schön, Gerhard, dass du's gefunden hast. Ein ATmega1284P hat JTAG, da könntest du übrigens auch Breakpoints auf Daten setzen und dann sehen, wer da was überschreibt.
Jörg W. schrieb: > chris_ schrieb: >> An die AVR-GCC Experten: Wie ist es mit einen Stack-Überlauf? > > Unwahrscheinlich. > >> Wie groß >> ist eigentlich der Stack und wo liegt er? > > By default werden die Daten von unten nach oben im SRAM abgelegt, > der Stack vom Ende nach unten. Solange der SRAM nicht schon zu 98 % > mit statischen/globalen Daten gefüllt ist, läuft der Stack da > normalerweise nicht rein. > > Schön, Gerhard, dass du's gefunden hast. Ein ATmega1284P hat JTAG, > da könntest du übrigens auch Breakpoints auf Daten setzen und dann > sehen, wer da was überschreibt. Die JTAG Pins sind zur Not über einen Header zugänglich . Z.Zt. habe ich allerdings den JTAG Port über eine Fuse Setting abgeschaltet weil ich einige der JTAG für die Applikation brauche. Der Fehler war allerdings, nachdem Ihr mich mit der Nase auf die mögliche Ursache gestupst hattet, gleich gefunden. Dieser Bug existierte, wie ich jetzt mit rotem Gesicht zugeben muß, schon viele Jahre lang auf allen möglichen MCUs und Projekten ohne sich jemals vorher auf diese Art bemerkbar zu machen. Ist also ein Fehler mit Stealth Verhalten - Sehr nasty!!! Gruss, Gerhard
Gerhard O. schrieb: > Z.Zt. habe ich allerdings den JTAG Port über eine Fuse Setting > abgeschaltet weil ich einige der JTAG für die Applikation brauche. Nicht ganz so geschickt. Schalt' ihn lieber per JTD-Bit ab, dann kannst du bei Bedarf das JTAG trotzdem noch nutzen: entweder eine Firmware einspielen, die JTD eben nicht setzt, oder genau auf die timed sequence, mit der man JTD aktiviert, erstmal einen Breakpoint, dann per single-step durch – damit ist die timed sequence im Eimer, und das JTAG bleibt aktiviiert. ;-) Wenn man an die JTAG-Pins dann ein paar nicht ganz so wichtige LEDs klemmt, stört das auch nicht so sehr.
Vielen Dank für Deine JTAG Hinweise. Bis jetzt hatte ich mich mit den JTAG Funktionen des 1284P nicht befasst weil ich ursprünglich keine Absicht gehabt hatte JTAG zu verwenden. Welche JTAG Debug Software ist für Windows) am günstigsten und welches JTAG Interface hat sich hier am besten bewährt? mfg, Gerhard Jörg W. schrieb: > Gerhard O. schrieb: >> Z.Zt. habe ich allerdings den JTAG Port über eine Fuse Setting >> abgeschaltet weil ich einige der JTAG für die Applikation brauche. > > Nicht ganz so geschickt. Schalt' ihn lieber per JTD-Bit ab, dann > kannst du bei Bedarf das JTAG trotzdem noch nutzen: entweder eine > Firmware einspielen, die JTD eben nicht setzt, oder genau auf die > timed sequence, mit der man JTD aktiviert, erstmal einen Breakpoint, > dann per single-step durch – damit ist die timed sequence im Eimer, > und das JTAG bleibt aktiviiert. ;-) Wenn man an die JTAG-Pins dann > ein paar nicht ganz so wichtige LEDs klemmt, stört das auch nicht so > sehr.
Gerhard O. schrieb: > Welche JTAG Debug Software ist für Windows) am günstigsten Für Windows: nimm das Hersteller-Tool, Atmel Studio. > und welches > JTAG Interface hat sich hier am besten bewährt? Die gehen alle, aktuell (falls du noch keinst hast) würde ich das Atmel-ICE kaufen. Bietet das beste Preis-/Leistungsverhältnis.
Jörg W. schrieb: > Gerhard O. schrieb: >> Welche JTAG Debug Software ist für Windows) am günstigsten > > Für Windows: nimm das Hersteller-Tool, Atmel Studio. > >> und welches >> JTAG Interface hat sich hier am besten bewährt? > > Die gehen alle, aktuell (falls du noch keinst hast) würde ich das > Atmel-ICE kaufen. Bietet das beste Preis-/Leistungsverhältnis. Danke für Deine Hinweise. Ich habe mal kurz recherchiert und fand ein Atmel JTAG-ICE: http://www.ebay.ca/itm/like/111529325052?limghlpsr=true&hlpht=true&ul_noapp=true&hlpv=2&chn=ps&lpid=116&ops=true&viphx=1 Werde ich mir auf alle Fälle zulegen und ausprobieren damit ich nächstes mal für den "Fall aller Fälle" gewappnet bin;-) Mit JTAG habe ich bis jetzt nur mit LPC ARM und STM32 gearbeitet. Wäre toll wenn das auf dem AVR genauso gut funktionieren würde. Bin froh dass ich die JTAG Pins schon auf einem Header zugänglich habe. Das Kabel Pinout wird allerdings nicht stimmen. Aber das ist ja kein wirkliches Problem. Gruss, Gerhard
Gerhard O. schrieb: > Ich habe mal kurz recherchiert und fand ein Atmel JTAG-ICE: Nope. Das ist entweder ein AVRISPmkII (so man auf dem schwammigen Foto erkennen kann) oder ein billigst-Clone des 15 Jahre alten ersten JTAGICE von Atmel (später zuweilen als JTAGICEmkI bezeichnet). Ersteres ist ein reiner Programmer, letzteres völlig obsolet, damit kann man nur hornaltes Zeug debuggen (maximal ATmega128, AT90CAN128 oder ATmega169). Ich meine dieses hier: http://www.digikey.com/product-detail/en/ATATMEL-ICE-BASIC/ATATMEL-ICE-BASIC-ND/4753381 bzw. mit allen Kabeln: http://www.digikey.com/product-detail/en/ATATMEL-ICE/ATATMEL-ICE-ND/4753379 Gibt's auch als nacktes Board: http://www.digikey.com/product-detail/en/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383 aber den Stress, sich die Kabel für Stecker mit 1,27 mm Rastermaß selbst zu fummeln, würde ich mir an deiner Stelle nicht antun.
:
Bearbeitet durch Moderator
Bin froh, dass ich den noch nicht bestellt habe. Das wäre offensichtlich ins Auge gegangen. Ich wunderte mich schon dass D.K. den von eBAy nicht im Lieferprogramm aufführte. Danke. Der Link mit den Kabel scheint keine schlechte Wahl zu sein, da viele Anschlussmöglichkeiten bestehen. Für ein neues Design könnte man dann schon von Anfang an den JTAG Anschluss kompatibel zu belegen. Gerhard Jörg W. schrieb: > Gerhard O. schrieb: >> Ich habe mal kurz recherchiert und fand ein Atmel JTAG-ICE: > > Nope. Das ist entweder ein AVRISPmkII (so man auf dem schwammigen > Foto erkennen kann) oder ein billigst-Clone des 15 Jahre alten > ersten JTAGICE von Atmel (später zuweilen als JTAGICEmkI bezeichnet). > Ersteres ist ein reiner Programmer, letzteres völlig obsolet, damit > kann man nur hornaltes Zeug debuggen (maximal ATmega128, AT90CAN128 > oder ATmega169). > > Ich meine dieses hier: > > http://www.digikey.com/product-detail/en/ATATMEL-ICE-BASIC/ATATMEL-ICE-BASIC-ND/4753381 > > bzw. mit allen Kabeln: > > http://www.digikey.com/product-detail/en/ATATMEL-ICE/ATATMEL-ICE-ND/4753379 > > Gibt's auch als nacktes Board: > > http://www.digikey.com/product-detail/en/ATATMEL-ICE-PCBA/ATATMEL-ICE-PCBA-ND/4753383 > > aber den Stress, sich die Kabel für Stecker mit 1,27 mm Rastermaß > selbst zu fummeln, würde ich mir an deiner Stelle nicht antun.
Gerhard O. schrieb: > Für ein neues Design könnte man dann schon von Anfang an den JTAG > Anschluss kompatibel zu belegen. Und wenn du die „Luxusversion“ kaufst, dann hast du noch diesen „Tintenfisch-Adapter“, mit dem du auf einem beliebigen Board die JTAG-Pins abgreifen kannst. ;-)
Jörg W. schrieb: > Gerhard O. schrieb: >> Für ein neues Design könnte man dann schon von Anfang an den JTAG >> Anschluss kompatibel zu belegen. > > Und wenn du die „Luxusversion“ kaufst, dann hast du noch diesen > „Tintenfisch-Adapter“, mit dem du auf einem beliebigen Board die > JTAG-Pins abgreifen kannst. ;-) Ist das die kleine Adapter Stecker Platine?
Angehängte Dateien:
-
squid-cable.jpg
33 KB
Gerhard O. schrieb: > Ist das die kleine Adapter Stecker Platine? Nein, das Kabel hier.
Jörg W. schrieb: > Gerhard O. schrieb: >> Ist das die kleine Adapter Stecker Platine? > > Nein, das Kabel hier. Mit einiger Fantasie sieht es tatsächlich Tintenfisch Tentakel ähnlich;-) Gruss, Gerhard
Angehängte Dateien:
-
squid-cable-mkII.jpg
53 KB
Gerhard O. schrieb: > Mit einiger Fantasie sieht es tatsächlich Tintenfisch Tentakel > ähnlich;-) Beim Vorvorgänger (JTAGICEmkII) sah es einem solchen noch deutlich ähnlicher. ;) Dumm nur, dass sie das mit dem Widerstands-Farbcode-codierten Kabel nicht geschnallt haben und Pin 1 auf schwarz, Pin 2 auf weiß etc. gelegt haben.
Jörg W. schrieb: > Gerhard O. schrieb: >> Mit einiger Fantasie sieht es tatsächlich Tintenfisch Tentakel >> ähnlich;-) > > Beim Vorvorgänger (JTAGICEmkII) sah es einem solchen noch deutlich > ähnlicher. ;) > > Dumm nur, dass sie das mit dem Widerstands-Farbcode-codierten Kabel > nicht geschnallt haben und Pin 1 auf schwarz, Pin 2 auf weiß etc. > gelegt haben. Ja, das wäre mir auch lieber.
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.