Danni schrieb:> Das Ganze ist offenbar abhänig davon wie groß die Tabelle ist. Wenn man> "Dummy"-Zeile anfügt oder Zeilen wegläßt geht es mal gut oder schief.> Leider habe ich noch keinen Zusammenhang entdeckt.
Das hört sich eher nach fremdgehenden Zeigern an.
Übrigends, häng ein Besipiel, das den Fehler aufweist, als
compilierbaren(!) Quellcode an. So kanns ein anderer besser
nachvollziehen.
PS: Wo soll das hin?
> eeprom_block_table[] PROGMEM
eeprom oder flash (progmem)?
Hi
Vielleicht solltest du dich mal über den Unterschied zwischen EEMEM und
PROGMEM schlau machen. Das AVR-STudio ist mit Sicherheit bugfreier als
dein Programm.
MfG Spess
Hallo Floh,
Zur Erklärung:
eeprom_block_t eeprom_block_table[]
ist lediglich eine Tabelle im ROM (PROGMEM) mit einer EEPROM-Adresse,
einer RAM-Aresse, einem Function-Pointer und einer Länge (Byte).
Die EEPROM-Adresse ergibt sich z.B. aus einem EEPROM-Block:
static struct x_pos_tab_t eep_x_pos_20m
EEMEM={{{1,2},{3,4},{5,6},{7,8},{9,10},{11,12},{13,14},{15,16},{17,18},{
19,20},{21,22},{23,24},{25,26},{27,28},{29,30},{31,32},{33,34},{35,36},{
37,38},{39,40}},0xFF};
Dieser Block kann wahlweise auch nicht mit Dummy-Werten initialisiert
sein. Hat keinen Einfluß auf das Fehlerbild.
Der Code ist in jeder Konstellation (auch einer Fehlerhaften) der
Beispiele oben compilierbar, flashbar und stand-alone lauffähig! Nur
beim Debugger-Start bricht AVR Studio ab.
>Das hört sich eher nach fremdgehenden Zeigern an.
Was heißt das? Wie kann das nur den Debugger beeinflussen?
Gruß
Danni
Danni schrieb:> Zur besseren Ansicht ggf.in einen Textdatei kopieren.
Nein. Du hängst deinen Sourcecode als Dateianhang an deinen nächsten
Post.
Oder glaubst du irgend jemand hat Lust, sich durch den grauenhaft
zusammenkopierten Text durchzuwühlen?
mfg.
So jetzt gibt es neue Erkenntnisse:
Der Code selbst ist offenbar egal, die Länge aber nicht. Ich habe
einfach mal ein paar NOP (#define nop() asm volatile ("nop"))
in irgendeine folgende Funktioen gehängt um die Codegröße in kleinen
Schritten zu variieren.
Ergebnis:
1.Codegröße 0x1D04 (6660) Bytes: Programm läßt sich debuggen.
2.Codegröße 0x1A12 (6674) Bytes + 1 NOP: Programm läßt sich nicht
debuggen.
3.Codegröße 0x1A14 (6676) Bytes + 2 NOP: Programm läßt sich nicht
debuggen.
4.Codegröße 0x1A16 (6678) Bytes + 3 NOP: Programm läßt sich nicht
debuggen.
5.Codegröße 0x1A18 (6680) Bytes + 4 NOP: Programm läßt sich debuggen.
Sieht nach einem Aligment-Problem aus. Aber was kann das sein? Vor
vielen Jahren hatten wir mal das Problem mit einem Compiler der immer
muckte bei Codegrößen die durch 4096 oder 2048 (genau weiß ich es nicht
mehr) teilbar waren.
Ich werde morgen mal den NOP-Versuch in einem anderen C-File
wiederholen, um rauszukriegen, ob es nur von der globalen Größe abhängt
nur mit diesem Modul zu tun hat.
Ich tippe weiterhin auf ein Debugger-Problem.
Gruß,
Danni
Sorry, hatte mich in einer Zeile vertippt. Es sollte natürlich
1.Codegröße 0x1A10 (6672) Bytes: Programm läßt sich debuggen.
heißen.
So sieht die Stelle im Original aus:
Hallo!
der Code ist immer dann debugbar, wenn man irgendwo min. vier nops
einfügt. Es ist also vollkommen egal in welchem C-File (habe alle
probiert) oder welcher Funktion (habe ich natürlich nicht probiert). Man
muß also die gesamte ROM-Größe von der alten Größe bei der der Fehler
auftritt um min 8 Byte "wegbringen".
Geht nicht: .text 0x00000000 0x1a10
Geht: .text 0x00000000 0x1a18
Ich hab es bis zu 9 Nops probiert.
Geht: .text 0x00000000 0x1a22
Anscheinend habe ich mit meinem Code zufällig genau eine Grenze
getroffen, bei der der Degugger ein Problem hat.
Das gibt der Compiler im Fehlerfall aus (Compiler Option -Os):
AVR Memory Usage
----------------
Device: atmega16
Program: 6842 bytes (41.8% Full)
(.text + .data + .bootloader)
Data: 294 bytes (28.7% Full)
(.data + .bss + .noinit)
EEPROM: 503 bytes (98.2% Full)
(.eeprom)
Build succeeded with 3 Warnings...
Die drei Warnings sind ungenutzte Funktionen.
Falls jemand mal zufällig :-) die gleiche Codegröße hat, kann er ja
berichten ob das Problem dann auch auftritt. Für mich ist das Problem
nicht transparent.
Spätestens wenn das Programm erweitert wird, werde ich sehen, ob das
Problem dauerhaft verschwunden ist.
Gruß,
Danni
Hallo!
Ich habe mittlerweile das Programm um einige wenige neue Funktionen
erweitert und siehe da, die nops sind nicht mehr notwendig. Für mich ist
und bleibt es ein Bug im Debugger (Dragon) oder im AVR Studio. Es
scheint nur mit genau dieser Codegröße oder ggf. Vielfachen oder Teilern
davon aufzutreten.
In der Praxis tritt es deshalb vermutlich fast nie auf
(=Lottogewinn:-))oder wird falsch interpretiert. Erweitert man das
Programm ein wenig, ist der Fehler auch gleich wieder weg. Für mich ist
das Thema damit vorerst abgschlossen.
Gruß
Danni
Hi
>Erweitert man das>Programm ein wenig, ist der Fehler auch gleich wieder weg. Für mich ist>das Thema damit vorerst abgschlossen.
Der Dragon ist doch mittlerweile doch schon etwas verbreiteter. Wieso
tritt das Problem anscheinend nur bei dir auf?
Würde mir zu denken geben.
MfG Spess
@ Tassilo,
Super. Vielen Dank für die Info! Das ist exakt was ich vermutet habe.
Also doch ein Bug. Allerdings sehe ich keinen anderen Workaround als
den, den ich bereits gemacht habe (Code-Größe verändern). Da in dem
genannten Beitrag andere Codegrößen genannt wurden, denke ich (wie
vermutet), daß das Problem auch bei irgendwelchen Vielfachen auftritt.
Ob Atmel davon weiß und/oder ob ein Bugfix geplant ist würde ich auch
gern wissen, allerdings kann ich auch mit dem Workaround leben.
@all
Noch was:
Eigentlich ignoriere ich unqualifizierte Kommentare einfach, denn die
führen nur zu endlosen Diskussionen.
Hier eine Ausnahme, weil sie für mich ein Beispiel sind für die
"Stimmung" in manchen (wenigen) Postings:
1.
>Der Dragon ist doch mittlerweile doch schon etwas verbreiteter. Wieso>tritt das Problem anscheinend nur bei dir auf?>Würde mir zu denken geben.
Hat sich wohl erledigt. Ich behaupte ja auch nicht, daß Du der Einzige
bist, bei dem das Problem nicht auftritt, weil Dein Code nie die 20 Byte
Grenze überschritten hat. ;-)
2.
>Vielleicht solltest du dich mal über den Unterschied zwischen EEMEM und>PROGMEM schlau machen. Das AVR-STudio ist mit Sicherheit bugfreier als>dein Programm.
Ich denke, da weiß ich sehr gut Bescheid, weil mein Programm bisher
fehlerfrei läuft. War ja auch kein EEPROM- oder Programmfehler, sondern
ein AVR-Bug. Zugegebend, die von mir gezeigte ROM/EEPROM-Pointer-Stuktur
ist für das ungeübte Auge verwirrend.
3.
>Nachtrag: Wenn du wirklich meinst einen Bug gefunden zu haben, dann wäre>Atmel die richtige Anlaufstelle und nicht dieses Forum.
Nein, diese Forum soll Anderen helfen ähnliche Probleme zu
identifizieren und ggf. einen Workaround zu finden. Mir hat letztlich
die Antwort von Tassilo einen Bestätigung gegeben. Natürlich kann jetzt
auf AVR zugegangen werden, was bei der Häufung der Probleme vermutlich
aber bereits geschehen ist.
4.
>Nein. Du hängst deinen Sourcecode als Dateianhang an deinen nächsten>Post.>Oder glaubst du irgend jemand hat Lust, sich durch den grauenhaft>zusammenkopierten Text durchzuwühlen?
Dieser Befehlston ist absolut inakzeptabel. Das ist Kasernenplatz-Stil.
Auch wenn das Anliegen dahinter berechtigt ist, kann man es auch anders
sagen. Ich verbuche es mal unter "German Directness".
Ich bin relativ neu hier im Forum aber nicht neu in der
Embedded-SW-Entwicklung und war bisher immer nur lesend unterwegs.
Leider ist mir der Stil mancher (zum Glück weniger) Kommentare sehr
negativ aufgefallen. Es wird gemeckert und die Kompetenz des Schreibers
angezweifelt oder es wird sich überheblich profiliert und andere
lächerlich gemacht. Schade, in englischen Foren ist der Ton meist
kollegialer.
Gruß
Danni
Hallo Danni,
nutzt Du ausschließlich AVR Studio 4 oder auch die neue Version 5?
Mich würde interessieren ob Du den Bug auch mit AVR Studio 5 nachstellen
kannst?
Ich kann es leider nicht selbst testen, da ich (noch) keinen Dragon
besitze...
Viele Grüße
TheChief
@Danni: Lass dich nicht von diesen Leuten nerven, leider hat sich das
mittlerweile im Forum so eingebürgert das oftmals die Hälfte der
Antworten aus gemeckere besteht....
Aber SEHR GUT dass du diesen Fehler hier beschrieben hast, ich hatte
auch schon das gleiche Problem und weiß jetzt dass es nicht an meiner
Schaltung liegt. Wenn mein Atmega88 relativ voll war ging das Debuggen
ebenfalls nicht mehr. Nach einiger Zeit und einigen Codezeilen mehr
wollte es wieder laufen. Hab das erstmal auf zu lange Kabel, leichte
ESD,Überspannungs,was-auch-immer-Schäden usw. geschoben aber konnte
bisher nie den Grund finden.
Also nochmal danke für den Thread hier, das wird mir in Zukunft viel
Zeit ersparen! :-)
@Markus G.
> nutzt Du ausschließlich AVR Studio 4 oder auch die neue Version 5?
Nur die 4er.
> Mich würde interessieren ob Du den Bug auch mit AVR Studio 5 nachstellen> kannst?
Es ist mir nicht klar, ob der Dragon oder das Studio den Bug hat.
Ich habe mir zwar mal das Studio 5 runtergeladen, bisher aber noch nicht
installiert. Z.z. ist mir mein Projekt wichtiger, als mich wieder an
eine neu Toolumgebung zu gewöhnen. Ich will mir erst mal das neuste
Studio 4 3.3.0 installieren. Vielleicht ist der Bug da gefixt. Im Moment
tritt er ja nicht mehr auf, weil meine Codegröße verändert ist.
> Ich kann es leider nicht selbst testen, da ich (noch) keinen Dragon> besitze...
Dann hol ihn Dir. Ist ein tolles Teil.
Gruß
Danni
