Fastboot Bootloader: Timeout

[Chris R. (mrgreen)]

Hallo,

ich versuche, den Bootloader von Peter Dannegger auf einem 644P über 
Bluetooth zum Laufen zu bringen.
Auf dem PC verwende ich den Loader von FBoot von Bernhard Michler / 
Andreas Butti.

Über USB via FTDI funktioniert er, dort kann ich meine Hex-Files 
übertragen.

Wenn ich jetzt den FTDI durch einen UART-Bluetooth-Adapter ersetze, dann 
bricht der Vorgang bei 22% (und zwar immer bei 22%) ab.

Die Verbindung über Bluetooth klappt, ich kann mich mit einem 
Terminal-Programm mit meinem Atmega unterhalten.

Ich habe auch shcon mit den Optionen herumgespielt (Baudrate, Blocksize, 
TCDrain), und ich habe das Timeout im Sourcecode hochgedreht. Aber auch 
wenn ich lange warte, bricht er immer bei 22% ab.

Ich habe beobachtet, dass er auch beim Flashen via FTDI bei 22% jurz 
stehenbleibt, aber dann gleich weiterläuft.

Hat jemand einen Tipp? Irgendwelche Sendepuffer, Flush(), ...?
Warum kann ich über USB flashen aber über Bluetooth nicht?

Zwischen Atmega und meinem PC-Bluetooth-Dongle ist 1m Distanz, daran 
sollte es nicht scheitern.


Gruß
Chris

[Bernhard M. (boregard)]

Chris R. schrieb:
> Ich habe beobachtet, dass er auch beim Flashen via FTDI bei 22% jurz
> stehenbleibt, aber dann gleich weiterläuft.

Hi,

dann sind die 22% wahrscheinlich die Buffergröße (also das, was unter 
"Buffer :" angegeben ist), danach erwartet der Bootloader eine Antwort 
des Controllers.
Hast Du schon mal (mit source Änderung) die Daten, die vom Controller 
kommen, ausgeben lassen? Kommt da die Antwort nach den 22% (also hex 
0xA9)?

Gruß,
Bernhard

P.S.: welche version des bootloaders verwendest Du? Die aktuelle aus 
github: https://github.com/Boregard/FBoot-Linux

[Chris R. (mrgreen)]

Hallo,

ich habe den Master aus deinem github-Repo geladen.

Per USB geflasht sieht es so aus:

christian@christian:~/Basteln/Atmega/Himmel$ ./bootloader -b 38400 Release/Himmel.hex -d /dev/ttyUSB0 -p -v

=================================================
|           BOOTLOADER, Target: V2.1            |
|            (Jan  6 2013 15:23:36)             |
=================================================
Now program, verify device.
Port          : /dev/ttyUSB0
Baudrate      : 38400
File          : Release/Himmel.hex
Reading       : Release/Himmel.hex... File read.
Size          : 15842 Bytes
-------------------------------------------------
Waiting for device... /Rx: 166 (0xA6)
connectedRx: 166 (0xA6)
Rx: 170 (0xAA)
!
Rx: 171 (0xAB)
Rx: 168 (0xA8)
Rx: 3 (0x3)
Rx: 2 (0x2)
Rx: 1 (0x1)
Rx: 170 (0xAA)
Bootloader    : V2.1
Rx: 168 (0xA8)
Rx: 4 (0x4)
Rx: 30 (0x1E)
Rx: 150 (0x96)
Rx: 10 (0xA)
Rx: 170 (0xAA)
Target        : 1E960A ATmega644P
Rx: 168 (0xA8)
Rx: 3 (0x3)
Rx: 14 (0xE)
Rx: 0 (0x0)
Rx: 170 (0xAA)
Buffer        : 3584 Byte
Rx: 168 (0xA8)
Rx: 4 (0x4)
Rx: 0 (0x0)
Rx: 252 (0xFC)
Rx: 0 (0x0)
Rx: 170 (0xAA)
Size available: 64512 Byte
Rx: 170 (0xAA)
CRC enabled and OK.
Programming   : 0x00000 - 0x03DE1
Rx: 169 (0xA9)##############                                                                  ]  22%
Rx: 169 (0xA9)#################################                                               ]  45%
Rx: 169 (0xA9)####################################################                            ]  67%
Rx: 169 (0xA9)#######################################################################         ]  90%
Writing [#####################################################################################] 100%
Elapsed time  : 4.61 seconds, 3436 Bytes/sec.
Rx: 170 (0xAA)
Rx: 170 (0xAA)

 ++++++++++ Device successfully programmed! ++++++++++

Verify        : 0x00000 - 0x03DE1
Verifying [###################################################################################] 100%
Elapsed time  : 4.40 seconds, 3600 Bytes/sec.
Rx: 170 (0xAA)
Rx: 170 (0xAA)

 ++++++++++ Device successfully verified! ++++++++++

...starting application

Wenn ich deinen Loader ohne mein Debug-printf() betreibe, dann hängt er 
wie gesagt bei den 22%.
Wenn ich aber das printf() einbaue, dann stirbt er lange vorher:

Bluetooth und Debug-printf():

christian@christian:~/Basteln/Atmega/Himmel$ ./bootloader -b 38400 Release/Himmel.hex -d /dev/rfcomm0 -p -v

=================================================
|           BOOTLOADER, Target: V2.1            |
|            (Jan  6 2013 15:23:36)             |
=================================================
Now program, verify device.
Port          : /dev/rfcomm0
Baudrate      : 38400
File          : Release/Himmel.hex
Reading       : Release/Himmel.hex... File read.
Size          : 15842 Bytes
-------------------------------------------------
Waiting for device... |Rx: 166 (0xA6)
connectedRx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 166 (0xA6)
Rx: 170 (0xAA)
!
Rx: 171 (0xAB)
Rx: 168 (0xA8)
Rx: 3 (0x3)
Rx: 2 (0x2)
Rx: 1 (0x1)
Rx: 170 (0xAA)
Bootloader    : V2.1
Rx: 168 (0xA8)
Rx: 4 (0x4)
Rx: 30 (0x1E)
Rx: 150 (0x96)
Rx: 10 (0xA)
Rx: 170 (0xAA)
Target        : 1E960A ATmega644P
Rx: 168 (0xA8)
Rx: 3 (0x3)
Rx: 14 (0xE)
Rx: 0 (0x0)
Rx: 170 (0xAA)
Buffer        : 3584 Byte
Rx: 168 (0xA8)
Rx: 4 (0x4)
Rx: 0 (0x0)
Rx: 252 (0xFC)
Rx: 0 (0x0)
readval: ...Device does not answer!
Reading FLASHSIZE failed!

Bluetooth OHNE printf

christian@christian:~/Basteln/Atmega/Himmel$ ./bootloader -b 38400 Release/Himmel.hex -d /dev/rfcomm0 -p -v

=================================================
|           BOOTLOADER, Target: V2.1            |
|            (Jan  6 2013 15:23:36)             |
=================================================
Now program, verify device.
Port          : /dev/rfcomm0
Baudrate      : 38400
File          : Release/Himmel.hex
Reading       : Release/Himmel.hex... File read.
Size          : 15842 Bytes
-------------------------------------------------
Waiting for device... connected!
Bootloader    : V2.1
Target        : 1E960A ATmega644P
Buffer        : 3584 Byte
Size available: 64512 Byte
CRC enabled and OK.
Programming   : 0x00000 - 0x03DE1
Writing [###################                                                                  ]  22%
 ---------- Failed! ----------

 ---------- Programming failed! ----------

Gibt es da evtl. ein Timing-Problem? Ich verstehe aber grade nicht, 
wieso.
Das printf() habe ich in die com_getc eingebaut (Z.313). Das sollte aber 
keinen großen Einfluss auf den weiteren Programmablauf haben.



Interessanterweise ist der Puffer in beiden Fällen gleich groß, bei der 
Verbindung per USB bekommt dein Loader aber ein Antwort vom Chip.
Wenn ich mich mit einem Terminalprogramm mit meinem Baustein verbinde, 
erhalte ich aber auch Antworten über Bluetooth.

Der Bootlader von Peter Dannegger merkt doch aber überhaupt nicht, 
welches Übertragungsmedium ihn mit Daten versorgt...?

Gruß
Mr.Green

[Bernhard M. (boregard)]

Chris R. schrieb:
> Interessanterweise ist der Puffer in beiden Fällen gleich groß

die Buffer größe kommt ja von Peters Code vom ATMega, das ist der 
verfügbare Pufferspeicher.

Mein Verdacht ist auch ein Timingproblem, und daß sich der Bluetooth 
Adapter anders verhält bzgl. der IOCTLs.

Probiere das mal mit den Extremwerten: -t 1 -w 64 -r

Gruß,
Bernhard

[Chris R. (mrgreen)]

Er läuft dann zwar bis 100% durch, aber es einen CRC Fehler, das Verify 
schlägt fehl und das Programm startet nicht :(

[Chris R. (mrgreen)]

Hallo Bernhard,

muss ich davon ausgehen, dass du keine Idee mehr hast...?

Gruß
Chris

[Kille H. (kille)]

Hi,

sitze grade vor dem selben Problem.
Schön eine Lösung gefunden?

Grüße,
Kille

[Kille H. (kille)]

So hab jetzt einen client gefunden mit dem es geht. Zwar langsam aber es 
geht:
Der ist hier zu finden:
http://www.mikrocontroller.net/articles/Diskussion:Word_Clock_Variante_1

Wäre aber schön wenn es FBoot-Linux auch geht...

Grüße

[Bernhard M. (boregard)]

Hallo,

sorry, ich habe die letzten Postings hier übersehen...

Das Problem scheint immer das gleiche zu sein. Es geht, wenn die Bytes 
einzeln über Bluetooth geschickt werden, also kein Puffer benutzt wird.
Damitwird die maximale Übertragungsgeschwindikeit natürlich sehr 
langsam.

Man könnte die Wartezeit noch hochsetzen, z.B. -w 128...

Ich muß mir jetzt mal bluetooth adapter besorgen, um es zu testen, was 
verwendet ihrdenn so?

Gruß,
Bernhard

[Kille H. (kille)]

Hi Bernhard,

danke für das Feadback.
Also ich verwende den HC-05.
Z.B.
http://www.aliexpress.com/item/2-4G-GHz-Serial-Port-Bluetooth-Module-HC-05-Master-Slave-For-GPS-Receiver-MCU-Free/689579631.html

Ich werde das mit der Wartezeit testen!

Grüße