AVR Bootloader (Basis: xnutboot) Problem bei Programmübertragung

Hallo zusammen,

nachdem ich nun mal probiert habe, den Debugger zu bemühen, wurde der 
Flash mit der Applikation komplett beschrieben. Sogar mehr als komplett 
(siehe nachstehender Auszug):

:100000000C9466000C9485000C9485000C9485007B
:100010000C9485000C9485000C9485000C9485004C
:100020000C9485000C9485000C9485000C9485003C
:100030000C9485000C9485000C9485000C9485002C
:100040000C9485000C9485000C9485000C9485001C
:100050000C9485000C9485000C9485000C9485000C
:100060000C9485000C9485000C9485000C948500FC
:100070000C9485000C9485000C9485000C948500EC
:100080000C9485000C94AA000C9485000C948500B7
:100090000C9485000C9485000C9485000C948500CC
:1000A0000C9485000C9485000C9485000C948500BC
:1000B0000C9485000C9485000C9485000C948500AC
:1000C0000C9485000C9485000C94850011241FBEAF
:1000D000CFEFD1E2DEBFCDBF12E0A0E0B2E0EEE8AC
:1000E000F1E000E00BBF02C007900D92A030B10715
:1000F000D9F712E0A0E0B2E001C01D92A130B10733
:10010000E1F70E9487000C94C5000C94000080E089
:1001100090E290939B0080939A008DE080939100F1
:10012000109290008FEF80BB81BB80917100846042
:1001300080937100789441E050E021B380910002F7
:10014000BA0102C0660F771F8A95E2F72623209531
:1001500021BBF3CF1F920F920FB60F9211248F93F2
:10016000809100028F5F80930002809100028830AE
:1001700010F01092000210929500109294008F914E
:100180000F900FBE0F901F901895F894FFCF1A1A7A
:100190001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1ABF
:1001A0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1AAF
:1001B0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A9F
:1001C0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A8F
:1001D0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A7F
:1001E0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A6F
:1001F0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A5F
:10020000E1F70E9487000C94C5000C94000080E088
:1002100090E290939B0080939A008DE080939100F0
:10022000109290008FEF80BB81BB80917100846041
:1002300080937100789441E050E021B380910002F6
:10024000BA0102C0660F771F8A95E2F72623209530
:1002500021BBF3CF1F920F920FB60F9211248F93F1
:10026000809100028F5F80930002809100028830AD
:1002700010F01092000210929500109294008F914D
:100280000F900FBE0F901F901895F894FFCF1A1A79
:100290001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1ABE
:1002A0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1AAE
:1002B0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A9E
:1002C0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A8E
:1002D0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A7E
:1002E0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A6E
:1002F0001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A5E
:10030000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD
:10031000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED
:10032000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD
:10033000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCD
:10034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBD
:10035000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAD
...
...
...

ich weiß zwar nun nicht, woher diese 1A1A1A... Reihen kommen (hängt aber 
wahrscheinlich mit den Debuggerpausen zusammen), aber die Applikation 
(16Bit-Counter) läuft auf dem µC so, wie es sein soll.

Kann es sein, dass es ein zeitliches Problem bei der Übertragung gibt?
Kann es mir nicht so richtig erklären...

Ich bitte weiterhin um Eure Hilfe...

vG Stephan

Neuer Stand,

habe ein Programm mit TerTerm an den µC geschickt, welches kleiner als 
das vorherige ist: 268 Bytes, also etwas mehr als eine Seite. Diese 
Applikation hat es vollständig "automatisch" übertragen. Das 
Miniprogramm läuft auch (2 LEDs sollen blinken) aber der Flashdump zeigt 
wieder diese merkwürdigen 1A1A... -Einschübe. Diesmal habe ich keinen 
Debugger verwendet...:

test2.hex:

:100000000C9466000C947D000C947D000C947D0093
:100010000C947D000C947D000C947D000C947D006C
:100020000C947D000C947D000C947D000C947D005C
:100030000C947D000C947D000C947D000C947D004C
:100040000C947D000C947D000C947D000C947D003C
:100050000C947D000C947D000C947D000C947D002C
:100060000C947D000C947D000C947D000C947D001C
:100070000C947D000C947D000C947D000C947D000C
:100080000C947D000C947D000C947D000C947D00FC
:100090000C947D000C947D000C947D000C947D00EC
:1000A0000C947D000C947D000C947D000C947D00DC
:1000B0000C947D000C947D000C947D000C947D00CC
:1000C0000C947D000C947D000C947D0011241FBEC7
:1000D000CFEFD1E2DEBFCDBF12E0A0E0B2E0ECE0B6
:1000E000F1E000E00BBF02C007900D92A030B10715
:1000F000D9F70E947F000C9484000C9400008FEFCD
:0C01000080BB89EF81BBFECFF894FFCFDD
:00000001FF

Flash-Dump µC:

:100000000C9466000C947D000C947D000C947D0093
:100010000C947D000C947D000C947D000C947D006C
:100020000C947D000C947D000C947D000C947D005C
:100030000C947D000C947D000C947D000C947D004C
:100040000C947D000C947D000C947D000C947D003C
:100050000C947D000C947D000C947D000C947D002C
:100060000C947D000C947D000C947D000C947D001C
:100070000C947D000C947D000C947D000C947D000C
:100080000C947D000C947D000C947D000C947D00FC
:100090000C947D000C947D000C947D000C947D00EC
:1000A0000C947D000C947D000C947D000C947D00DC
:1000B0000C947D000C947D000C947D000C947D00CC
:1000C0000C947D000C947D000C947D0011241FBEC7
:1000D000CFEFD1E2DEBFCDBF12E0A0E0B2E0ECE0B6
:1000E000F1E000E00BBF02C007900D92A030B10715
:1000F000D9F70E947F000C9484000C9400008FEFCD
:1001000080BB89EF81BB0895F894FFCF1A1A1A1AA1
:100110001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A3F
:100120001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A2F
:100130001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1F
:100140001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A0F
:100150001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1AFF
:100160001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1AEF
:100170001A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1ADF
:100180000C947D000C947D000C947D000C947D00FB
:100190000C947D000C947D000C947D000C947D00EB
:1001A0000C947D000C947D000C947D000C947D00DB
:1001B0000C947D000C947D000C947D000C947D00CB
:1001C0000C947D000C947D000C947D0011241FBEC6
:1001D000CFEFD1E2DEBFCDBF12E0A0E0B2E0ECE0B5
:1001E000F1E000E00BBF02C007900D92A030B10714
:1001F000D9F70E947F000C9484000C9400008FEFCC
:10020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
:10021000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEE
:10022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE
..
..
..

danach scheint die Applikation zu "wiederholen",... ich weiß nicht so 
recht, wo ich anfangen muss, den Fehler zu suchen...

Ich bitte um Hilfe!!!

vG Stephan

Stephan W. schrieb:

> zunächst für meinen 1281 angepasst und folgendes verändert:
>
> - den Baudratenfaktor auf 25 gestellt (19.2kBaud bei 8MHz Clock)
> - die intern verwendeten Funktionen inb() und outb() ersetzt, da ich die
> "could not find reference to..." - Fehlermeldungen nicht beseitigen
> konnte, da ich nicht wusste, welche auf welche Headerfiles dafür
> zurückgegriffen werden muss. Zumal habe ich gelesen, dass Abfragen, ob
> ein bestimmtes Bit in einem Register gesetzt ist nun anders gemacht
> wird:
>
> also: beispielsweise:
>
> while (!(UCSR0A & (1<<UDRE0))) statt  while ((inb(UCSR0A) & _BV(UDRE))
> == 0)
>

Da würde ich noch einmal ansetzen.
Wenn die Arbeitshypothese lautet:
  Das Original funktoniert
dann hast du höchst wahrscheinlich hier irgendwo einen Fehler gemacht.

In diesem speziell Fall würde ich den Code nicht umschreiben, sonden mit 
ansehen was die 'fehlenden Funktionen' (*) ziemlich offensichtlich 
machen müssen und die dann selber implementieren. Die sind nicht schwer 
zu machen, aber ein Fehler mit einem ! das beim Umschreiben sein sollte 
oder auch nicht sein sollte, ist schnell gemacht.

Ziel: Den Originalcode, so wie er ist compilierbar und damit lauffähig 
zu kriegen. Der wird dann getestet und erst dann, wenn er funktioniert 
fang ich an, ihn umzuschreiben.

(*) Höchst wahrscheinlich sind das sogar Makros

Hallo Karl-Heinz,

danke, dass du Dich meinem Problem annimmst. Ich stimme Dir voll und 
ganz zu, dass das Umschreiben zu Beginn möglicherweise keine gute Idee 
war. Allerdings bin ich beim suchen nach diesen Funktionen / Makros 
nicht so wirklich weit gekommen. Eigentlich müssten die doch irgendwo in 
den per include eingebundenen Dateien verzeichnet sein, oder? Kannst du 
mir einen Ansatz geben, wo ich noch danach suchen kann?

nochmals vielen Dank für Deine Unterstützung,

vG Stephan

Stephan W. schrieb:
> Hallo Karl-Heinz,
>
> danke, dass du Dich meinem Problem annimmst. Ich stimme Dir voll und
> ganz zu, dass das Umschreiben zu Beginn möglicherweise keine gute Idee
> war. Allerdings bin ich beim suchen nach diesen Funktionen / Makros
> nicht so wirklich weit gekommen. Eigentlich müssten die doch irgendwo in
> den per include eingebundenen Dateien verzeichnet sein, oder? Kannst du
> mir einen Ansatz geben, wo ich noch danach suchen kann?

Sieh dir an, wie sie verwendet werden.
An 3 oder 4 Stellen.

Spätestens dann hast du mit Sicherheit eine Hypothese, was diese 
Funktionen machen sollen und schreibst sie dann einfach neu.

inb   klingt nach  'Input Byte' und wird ganz einfach nur das
      PIN Register abfragen (aber überprüfe das an ein paar Stellen
      mit der dort vorhandenen Verwendung)
outb  wiederrum klingt nach 'Output Byte' und die Hypothese könnte
      lauten: Ausgabe aufs PORT Register.
      (Wieder, an ein paar STellen kontrollieren, ob das so sein kann)

Karl heinz Buchegger schrieb:
> Stephan W. schrieb:
>> Hallo Karl-Heinz,
>>
>> danke, dass du Dich meinem Problem annimmst. Ich stimme Dir voll und
>> ganz zu, dass das Umschreiben zu Beginn möglicherweise keine gute Idee
>> war. Allerdings bin ich beim suchen nach diesen Funktionen / Makros
>> nicht so wirklich weit gekommen. Eigentlich müssten die doch irgendwo in
>> den per include eingebundenen Dateien verzeichnet sein, oder? Kannst du
>> mir einen Ansatz geben, wo ich noch danach suchen kann?
>
> Sieh dir an, wie sie verwendet werden.
> An 3 oder 4 Stellen.
>
> Spätestens dann hast du mit Sicherheit eine Hypothese, was diese
> Funktionen machen sollen und schreibst sie dann einfach neu.
>
> inb   klingt nach  'Input Byte' und wird ganz einfach nur das
>       PIN Register abfragen (aber überprüfe das an ein paar Stellen
>       mit der dort vorhandenen Verwendung)
> outb  wiederrum klingt nach 'Output Byte' und die Hypothese könnte
>       lauten: Ausgabe aufs PORT Register.
>       (Wieder, an ein paar STellen kontrollieren, ob das so sein kann)


Ich bin mir ziemlich sicher, das die Arbeits-Hypothese stimmt

1

static void SendOctet(char ch)

2

{

3

    /* This may differ on your device. */

4

    while ((inb(UCSR0A) & _BV(UDRE)) == 0);

5

    outb(UDR0, ch);

6

}

Passt wie die Faust aufs Auge

Also:

1

#define outb(p,b)   (p) = (b)

2

#define inb(p)      (p)

3

#define _BV(b)      (1<<(b))

Hallo Karl-Heinz,

ok, jetzt bin ich auch fündig geworden, wo die Definitionen stehen: 
deprecated.h heißt das Zauberfile. Da die Befehle, wie der Name schon 
vermuten lässt, schon etwas eingestaubt sind und nicht mehr benutzt 
werden, habe ich jene Headerdatei manuell in die xnutboot.c eingebunden 
und konnte das Programm auch fehlerfrei kompilieren, nachdem ich 
natürlich die Registerbitbezeichnungen auf meinen ATMEGA1281 angepasst 
habe:

RXEN --> RXEN0
TXEN --> TXEN0
RXC --> RXC0
UDRE --> UDRE0

Das Problem bleibt leider das gleiche:

die *.bin-Datei lässt sich übertragen, bricht aber bei 96,5% laut 
Teraterm ab. Im Flash-Hex-Dump ist wieder zu sehen, dass nach der ersten 
Seite nix mehr im Flash geschrieben wurde.

Nochmal zu den inb() und outb()-Funktionen:

Für mich sagt while ((inb(UCSR0A) & _BV(UDRE)) == 0); folgendes aus:
"Warte solange, wie das UDRE-Bit im UCSR0A-Register nicht gesetzt ist"

Meine Syntax, die auch in den Tutorials hier so verwendet wird:
while (!(UCSR0A & (1<<UDRE0))) könnte man auch so schreiben:
while((UCSR0A & (1<<UDRE0))==0), womit man das gleiche hätte, wie 
oben,... oder?

Na gut, also scheint es an den von mir geänderten Befehlen nicht zu 
liegen... Aber du hattest völlig recht, ich hätte erst das Original 
testen und dann meckern sollen :-)

Hast du eine Idee, wie ich nun weitermachen kann? Rein von der 
Programmierlogik her erkenne ich nämlich keinen Fehler im Quellcode...

Ich würde mich freuen, wenn du noch weitere Hinweise für mich hast...

vG und nochmals vielen Dank,

Stephan

Neue Erkenntnis(?!):

mir ist doch vorhin schonmal aufgefallen, dass der Flashinhalt korrekt 
geschrieben wird, sobald ich mir das ganze im Debugger anschaue und beim 
Durchhangeln "künstlich Pausen erzeuge". Ich habe nun mal eben auch im 
Quelltext künstlich Pausen vor dem Aufruf der Funktion zum eigentlichen 
Flashen erzeugt mittels

for(i=0;i<1000;i++) {_delay_ms(1);}

Damit habe ich zwar nun je nach Programmgröße die eine oder andere Pause 
drin (wäre ohne natürlich glücklicher), aber irgendwie scheint mein 
Bootloader und Teraterm nicht ganz "im Takt" zu tanzen. Mein Datenblatt 
verät mir, dass der von mir eingestellte Baudwert (25, für 19.2kBaud bei 
8Mhz CLK) eine Fehlerquote von 0.2% hat. Kann da der Fehler liegen???
Ich vermute mal, dass es irgendwie damit zusammenhängt, aber würde dazu 
eben gern die Meinung von ein paar AVR-Kennern mit mehr Erfahrung 
wissen.

@Karl-Heinz: was meinst du dazu?

vlG Stephan

Stephan W. schrieb:

> Bootloader und Teraterm nicht ganz "im Takt" zu tanzen. Mein Datenblatt
> verät mir, dass der von mir eingestellte Baudwert (25, für 19.2kBaud bei
> 8Mhz CLK) eine Fehlerquote von 0.2% hat. Kann da der Fehler liegen???

Eher nicht.
0.2% ist weit unter dem zulässigen Fehler. Der liegt bei ca. 3%

> Ich vermute mal, dass es irgendwie damit zusammenhängt, aber würde dazu
> eben gern die Meinung von ein paar AVR-Kennern mit mehr Erfahrung
> wissen.

Hmm. Dein TerraTerm, welches XModem Protokoll benutzt das.
Das ältere mit einer Blockgröße von 123 Bytes, oder das neuere XModem1K 
mit einer Blockgröße von 1K Byte

>Eher nicht.
>0.2% ist weit unter dem zulässigen Fehler. Der liegt bei ca. 3%

ok, gut zu wissen. Heißt das, ich sollte bei der Wahl des 
Baudratenfaktors stets auf die magische 3%-Grenze achten?

>Hmm. Dein TerraTerm, welches XModem Protokoll benutzt das.
>Das ältere mit einer Blockgröße von 123 Bytes, oder das neuere XModem1K
>mit einer Blockgröße von 1K Byte

Hier hast du dich wohl verschrieben. 132 Bytes statt 123 Bytes... 
TeraTerm unterstütz alle 3 bekannten Arten von XMODEM (Standard 128 Byte 
Daten mit 1 Byte Prüfsumme, XMODEM CRC (mit 2Byte CRC), XModem1K mit 1K 
Datenblockgröße). Ich verwende bei mir die Standardvariante. Bei 
Teraterm kann ich den gewünschten Modus explizit auswählen.

vG Stephan

Stephan W. schrieb:
>>Eher nicht.
>>0.2% ist weit unter dem zulässigen Fehler. Der liegt bei ca. 3%
>
> ok, gut zu wissen. Heißt das, ich sollte bei der Wahl des
> Baudratenfaktors stets auf die magische 3%-Grenze achten?

Yep.

>
>>Hmm. Dein TerraTerm, welches XModem Protokoll benutzt das.
>>Das ältere mit einer Blockgröße von 123 Bytes, oder das neuere XModem1K
>>mit einer Blockgröße von 1K Byte
>
> Hier hast du dich wohl verschrieben. 132 Bytes statt 123 Bytes...
> TeraTerm unterstütz alle 3 bekannten Arten von XMODEM (Standard 128 Byte
> Daten mit 1 Byte Prüfsumme, XMODEM CRC (mit 2Byte CRC), XModem1K mit 1K
> Datenblockgröße). Ich verwende bei mir die Standardvariante. Bei
> Teraterm kann ich den gewünschten Modus explizit auswählen.

Gut.
D.h. du kennst den Unterschied.

Hmm.

Karl heinz Buchegger schrieb:
> Gut.
>
> D.h. du kennst den Unterschied.
>
>
>
> Hmm.


Ja, der Unterschied ist mir mittlerweile bekannt. Ich denke, wir müssen 
weiter auf Zeitlicher Ebene denken,... aber wo soll man da am besten 
ansetzen?

Kannst du mir vielleicht noch ein alternatives Tool zu Teraterm nennen, 
sodass man einen Softwarefehler dieserseits ausschließen kann?

Hast du bei Dir die Möglichkeit, den Bootloader zu testen?

vG Stephan

Habe ganz vergessen, dass es in der WindowsXP-Welt noch sowas wie 
Hyperterminal gibt. Mit dem Programm funktioniert es wunderbar, auch 
ohne künstliche Wartezyklen... was sagt man dazu. Ich werde es nun 
auchmal von der Unixseite aus Testen, indem ich Minicom probieren...

Ich danke Dir schonmal für Deine Unterstützung. Wenn es wieder Probleme 
gibt, führe ich diesen Thread weiter.

also, tausend Dank für die geopferte Zeit,

vG Stephan Weiser

Stephan W. schrieb:

> Ich danke Dir schonmal für Deine Unterstützung. Wenn es wieder Probleme
> gibt, führe ich diesen Thread weiter.
>
> also, tausend Dank für die geopferte Zeit,

Ich hätte sowieso keinen Vorschlag mehr gehabt :-)