Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[frank]

hallo dirk,

ich habe probleme mit dem bootloader v0.6.1. da du die letzte zeit am bootloader geschraubt hast, spreche ich dich mal direkt an. eigentlich soll ein:

Code Auswählen Erweitern

set <dev> fwUpdate <filename> [boottime]

in fhem ein automatisches starten des bootloaders auslösen. aber da tut sich nichts. könnte es sein, dass du diesen fall in deinen erweiterungen zum bootloader übersehen hast. fhem bricht das update ab mit:

Code Auswählen Erweitern

fwUpdate   fail:notInBootLoader   2014-10-09 19:38:18

der code in bootloader.c macht mir den eindruck, dass ausschliesslich mit configtaste oder misslungenem crc-check das booten ausgelösst werden kann.

Code Auswählen Erweitern

/**
* Check config button pressed after reset, then start bootloader. Else start application.
*/
if( bitRead(INPUT_CONFIG_BTN, PIN_CONFIG_BTN) ) { // check if button not pressed (button must be at high level)
#if CRC_FLASH == 1
if (crcOk) {
startApplication(); // then start Application
}
#else
startApplication(); // then start Application
#endif
}


hast du eine idee?

gruss frank

[Dirk]

Hallo Frank,

eigentlich soll ein:

Code Auswählen Erweitern

set <dev> fwUpdate <filename> [boottime]

in fhem ein automatisches starten des bootloaders auslösen. aber da tut sich nichts. könnte es sein, dass du diesen fall in deinen erweiterungen zum bootloader übersehen hast.

Der Bootloader startet zuerst und starten im Anschluss die "normale" Anwendung auf dem AVR.
Wenn das Firmewareupdate also automatisch starten soll, muss die Anwendung diesen Befehl implementieren und in den den Bootloader springen.
Der Bootloader ist zu dieser Zeit ja gar nicht aktiv und kann das nicht auslösen.

der code in bootloader.c macht mir den eindruck, dass ausschliesslich mit configtaste oder misslungenem crc-check das booten ausgelösst werden kann.

Das mit der Config-Taste ist ein Workaround.
Wenn die Anwendung auf dem AVR den Bootloader selber starten kann, dann muss nach dem Start des Bootloaders einmal die Config-Taste gedrückt werden. Der Bootloader wartet dann ca. 15 sek. auf das Drücken der Taste. Das wird durch blinken der Status-LED signalisiert.
Einige Beiträge weiter vorne gab es dazu mal eine Diskussion.

Hintergrund der Aktion:
Da wir nicht nicht AES-Signiert kommunizieren können, kann quasi auch ein Angreifer den Bootloader aus der Ferne starten und ggf. eine Schadhafte Firmware flashen. Das soll durch den erzwungen manuellen Eingriff verhindert werden.

Wenn man das so nicht möchte, muss man den Bootloader etwas verändern. Am einfachsten ist es den ohne Definition des Config-Buttons zu kompilieren.
Dann wurde der Bootloader aber auch bein einem "normalen" Start des entsprechenden Devices jedesmal erst mal ca. 10 Sekunden auf Update-Pakete arten bevor die Eigentliche Firmware gestartet wird.

Gruß
Dirk

[Dirk]

Ich habe heute mal probiert den Bootloader mit einem Update über die CCU zu füttern.
Genauer genommen mit der LXCCU und dem neuen LAN-GW.

Natürlich hat das erst mal nicht geklappt.
Die CCU verwendet hier während des Updates einen anderen Messagecounter.

Hier ist das Paket welches die CCU nach dem Switch in den 100k Mode schickt. Zum Vergleich das Paket vom Firmware-Update-Tool

# LXCCU mit HM-LAN-GW (2)
1F 2F 20 CB 1A CA E5 17 82 DC 10 5B 11 F8 15 47 0B 08 1A 1C 19 1D 1B C7 1C 00 1D B2 21 B6 23

# eQ-3 Windows-Tool oder flash-ota
0F 43 20 CB 1A CA E5 17 82 DC 10 5B 11 F8 15

Das erste Paket mit den Firmwaredaten sieht dann so aus:

rx: 3B 38 00 CA 1A CA E5 17 82 DC 00 80 0C 94 82 01 0C 94 69 32 0C 94 96 32 0C 94 2E 12 0C 94 09 12 0C 94 E4 11 0C 94 E7 16 0C 94 AA 01 0C 94 AA 01 0C 94 AA 01 0C 94 AA 01 0C 94 AA

Die Pakete sind ~15 Bytes länger als die von der Update-Software. Und Der Messagecounter ist hier jetzt nicht wie zu erwarten 0x30 sondern 0x38. Also genau 8 Bytes versetzt.

Jetzt habe ich im oberen Paket mal nach der 08 gesucht, und bin an Byte 17 fündig geworden.
Keine Ahnung ob hier tatsächlich der Offset steht. In meinem Fall hat es aber aktuell gepasst. Daher habe ich den Bootloader entsprechend angepasst, dass er das so berücksichtigt.

Ich hatte eigentlich gedacht dass das nun alles gewesen währ.
Tja, Pustekuchen. Der Messagecounter ist auch nach jedem vollständigen Block um diesen Offset zu erhöhen.

Und zu allerletzt läuft der Messagecounter in diesem Fall nicht bei 0xFF über, sondern schon bei 0x80.

Nungut. Ich habe das mal so eingebaut.
Da ich die erweiterte Message der CCU oben noch nicht komplett verstehe, kann es sein das das ganze so nur "zufällig" in meiner Umgebung funktioniert.

Kann noch jemand zu den Messages oben aufklärende Gedanken besteuern?

Ich habe das so in "meinen" Fork vom Bootloader eingecheckt.
Gleichzeitig habe ich noch zusätzliche Debugging-Ausgaben eingebaut die mit

Code Auswählen Erweitern

#define DEBUG                2
aktiviert werden.

Damit wird per UART jede Empfangene Paket ausgegeben.
Da das aber das Timing stört, musste ich dazu die Baudrate vom UART auf 115200 Baud erhöhen.
Blöderweise kann das bei AVR's ohne Quarz zu Problemen führen, da hier ggf. der interne Oszilator zu ungenau und am UART dann ab und zu falsche Zeichen ankommen. Daher sollte DEBUG 2 nur in einer bekannten Testumgebung gesetzt sein.

Anbei mal noch zwei komplette Traces der Updateprozesse.
Einmal vom flash-ota-tool und einmal von der CCU.

Damit das alles noch in 4k passen habe ich aus der cc.c die burst-spezifischen Funtkionen gelöscht. Die wurden eh nicht benutzt. Und da der Kompiler die nicht vollständig wegoptimiert hatte wurde dadurch noch mal einiges an Platz eingespart.

Vielleicht hat der eine oder andere ja Zugriff auf eine CCU2 oder LXCCU mit neuem HM-LAN-GW und kann das einmal testen.

Viele Grüße
Dirk

[frank]

hallo dirk,

danke für deine ausführungen.

Der Bootloader ist zu dieser Zeit ja gar nicht aktiv und kann das nicht auslösen.

genau deshalb wurde ja die watchdog-reset-funktionalität des mikroprozessors in den/die bootloader/firmware integriert. das war/ist ja bereits alles vorhanden und funktionierte auch schon.

Update:

Der Bootloader in neuer Version ist nun im GIT verfügbar: https://github.com/jabdoa2/Asksin_OTA_Bootloader

Neue Funktionen:

- Reboot-Möglichkeit aus der Applikation wird unterstützt (durch Watchdog Disable beim Start des Bootloaders)
- Serial kann per #define im Header der bootloader.c angepasst werden
- CRC Check ist optional möglich (Default: aus). Dazu muss das Binary vorbereitet werden, Details im Readme auf dem GIT. Dies verhindert das Starten von nicht vollständig korrekt übertragenen Files. Der Bootloader schickt dann immer wieder einen CB Request. Durch diese Maßnahmen ist es nun möglich, die Schalter ohne jeden Eingriff vor Ort und ohne die Notwendigkeit, den Strom abzustellen, gezielt zu updaten.

Bugreports, Anregungen, etc. gerne hier oder im GIT.

@Frank: Die Sicherheitslücke entsteht nur dann, wenn die Applikation den Reboot auch anbietet. Das sollte in der LIB konfigurierbar gemacht werden. Kommt noch...

danach habe ich die weitere entwicklung wohl nicht genau genug verfolgt. ich habe den thread nochmal von anfang des jahres bis heute nach dem bootloader durchstöbert. die neue funktionalität hast du dann hier dokumentiert:

Ist eingecheckt.
Standartmäßig wird 10 Sekunden gewartet. Das kann man aber im Devicefile konfigurieren.

Hier auch noch mal kurz die Erklärungen des Ablaufes und der Blink-Sequenzen

• 
  Wenn noch kein Code im AVR ist, oder wenn falscher Code im AVR, z.B. aus einem vorherigem fehlerhaften Flashversuch:
  
  
  
  • Nach dem Einschalten blinkt die LED kurz (Bootloader gestartet)
  • dann blinkt die LED noch einmal mal kurz und der Loader meldet sich beim Flash-Programm
  • Jetzt wird ca. 10 sek. auf die Antwort vom Flash-Programm gewartet.
  • Während des flashens blinkt die LED schnell.
  • Sollte während des Flashens ein Fehler auftreten also der CRC-Check nach dem Flashen nicht ok sein, dann leuchtet die LED für ca. 2 sek. (CRC-Fehler). Der Bootloader resettet den AVR, und es geht von vorne los. Die LED leuchtet auch nach Ablauf von ca. 10 Sekunden für 2 Sekunden rot, wenn kein Flashen gestartet wurde.
    
    


• 
  Wenn gültiger Code im AVR ist und das Gerät eingeschaltet wurde:
  
  
  
  • Nach dem Einschalten blinkt die LED kurz (Bootloader gestartet)
  • Das Hauptprogramm wird ohne weitere Wartezeit gestartet
    
    
  Oder während des Einschaltens wird die Config-Taste gedrückt gehalten:
  
  
  
  • Nach dem Einschalten blinkt die LED kurz (Bootloader gestartet)
  • alle weiteren Schritte siehe Punkt 1
  
  
• 
  Wenn das Hauptprogramm den AVR durch einen Watchdog-Reset neu gestartet hat, z.B. durch einen Funkbefehl:
  
  
  
  • Nach dem Reset blinkt die LED kurz (Bootloader gestartet)
  • Für einen vorher festgelegte Zeit (z.B. 10 sek) blinkt die LED kurz und wiederholend. Das Blinken zeigt an, dass der Bootloader auf das Drücken der Config-Taste wartet.
  • Wird innerhalb dieser Zeit die Taste nicht gedrückt, startet das Hauptprogramm.
  • Wird die Taste innerhalb dieser Zeit gedrückt, startet der Flashvorgang wie unter Punkt 1.1 beschrieben.

Dieser ganze Vorgang funktioniert wie oben beschrieben nur wenn der CRC-Check aktiviert ist.
Ansonsten wird immer auf das Drücken der Taste gewartet, da der AVR nicht feststellen kann ob sich gültiger Code in der Programsection befindet.

Wenn man das so nicht möchte, muss man den Bootloader etwas verändern. Am einfachsten ist es den ohne Definition des Config-Buttons zu kompilieren.
Dann wurde der Bootloader aber auch bein einem "normalen" Start des entsprechenden Devices jedesmal erst mal ca. 10 Sekunden auf Update-Pakete arten bevor die Eigentliche Firmware gestartet wird.

ich finde die funktionalität, wie sie zuletzt von unimatrix implementiert war, zumindestens für den sw1pbu, am sinnvollsten. wenn der "sicherheitscheck" (tasterbestätigung) wieder in die firmware ausgelagert wird, spart das natürlich auch platz im bootloader und man kann die routine bequemer entwickeln und verändern. so würde jeder watchdog-reset automatisch den bootloader starten. wenn man den reset in der applikation unterdrückt/nicht ausführt, kann auch niemand ungewollt updates machen. diese variante halte ich für die universellste. dann kann jeder die freischaltung des automatischen updates in seinen applikationen programmieren wie er meint, das machen zu müssen.

desweiteren gibt es beim sw1pbu noch das problem, dass bei einem update unter verwendung der eq3-sw mit hmusb eine möglichkeit geschaffen werden muss, um den flashvorgang zu starten. irgendeine configtaster betätigung um in den bootloader zu kommen. das kann dann auch bequem und komfortabel in der applikation gemacht werden. ansonsten bliebe nur die variante mit poweron-reset, verbunden mit dem ausbau des schalters (no-go).

den vorschlag mit dem kompletten wegfall des schalters finde ich nicht so gut. die möglichkeit bei poweron-reset durch tasterbetätigung in den bootloader zu gelangen gefällt mir als "notausstieg" sehr gut, weswegen ich sie auf alle fälle behalten möchte. um die beschriebene funktionalität zu bekommen habe ich die bootloader.c bei mir entsprechend geändert. die if-anweisung mit dem 10s-taster habe ich ganz beseitigt und die if-anweisung zum ausstieg in die applikation wie folgt geändert:

Code Auswählen Erweitern

if( bitRead(INPUT_CONFIG_BTN, PIN_CONFIG_BTN) && !watchdogReset) { // check if button not pressed (button must be at high level)
#if CRC_FLASH == 1
if (crcOk) {
startApplication(); // then start Application
}
#else
startApplication(); // then start Application
#endif
}

das läuft bisher sehr gut. eigentlich wollte ich gleich deine neue bootloader-version benutzen. komischerweise schaffe ich es aber nicht deine version im git durch clonen zu mir zu bekommen. es erscheint immer nur die version aus jans git. seltsam. musst du da eventuell erst noch etwas freischalten?

hast du deine neue version eventuell mit fhem probiert? mit dem bootloader v0.6.1 funktioniert es bei mir auch nicht. hast du ja schon erwähnt. irgendwie kommt da wohl das umschalten in den 100k-modus zu spät. werde ich mir aber noch anschauen.

meinen neuen bootloader hatte ich versucht als eq3-file über ota zu flashen. da ich keine ahnung hatte, was ich bei "srec" angeben sollte, habe ich einfach die 8k einstellungen für den schalter benutzt. ging natürlich voll in die hose.    kannst du mir sagen mit welchen einstellungen die 4k/8k versionen des bootloaders verarbeitet werden müssen? oder ist diese möglichkeit (noch) nicht vorhanden? ich hatte verstanden, dass das gehen sollte.

gruss frank

[Dirk]

ich finde die funktionalität, wie sie zuletzt von unimatrix implementiert war, zumindestens für den sw1pbu, am sinnvollsten. wenn der "sicherheitscheck" (tasterbestätigung) wieder in die firmware ausgelagert wird, spart das natürlich auch platz im bootloader und man kann die routine bequemer entwickeln und verändern.

Da hast du recht. Finde ich grundsätzlich gut.

dann kann jeder die freischaltung des automatischen updates in seinen applikationen programmieren wie er meint, das machen zu müssen.

Die Abfrage des Config-Buttons beim Start des Bootloaders sollte man aber auch noch drinn lassen. Damit man den Start des Bootloaders nach Rückkehr der Verorgungsspannung auch erzwingen kann.

Mal sehen aber ich wollte heute abend da eh noch mal rann. Dann kann ich das entsprechend erweitern / umbauen.

desweiteren gibt es beim sw1pbu noch das problem, dass bei einem update unter verwendung der eq3-sw mit hmusb eine möglichkeit geschaffen werden muss, um den flashvorgang zu starten. irgendeine configtaster betätigung um in den bootloader zu kommen. das kann dann auch bequem und komfortabel in der applikation gemacht werden.

Das muss auch in der Application gemacht werden.

das läuft bisher sehr gut. eigentlich wollte ich gleich deine neue bootloader-version benutzen. komischerweise schaffe ich es aber nicht deine version im git durch clonen zu mir zu bekommen. es erscheint immer nur die version aus jans git. seltsam. musst du da eventuell erst noch etwas freischalten?

Hm, wüsste ich nicht. mit diesem Link:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader
konnte ich "meine" Version Clonen

hast du deine neue version eventuell mit fhem probiert? mit dem bootloader v0.6.1 funktioniert es bei mir auch nicht.

Noch nicht. das teste ich auch noch mal.

meinen neuen bootloader hatte ich versucht als eq3-file über ota zu flashen.

Hast du die Bootloaderversion von Unimatrix die sich selber updaten kann drauf?
Funktioniert das zuverlässig? Vielleicht können wir die Versionen dann ja mal zusammenführen.
Ich habe mal ein neue Php-Datei gebaut mit der man das hex-file konvertieren kann. Hier wied auch das srec-zeugs gleich mit gemacht.
Das ist aber noch nicht ganz fertig daher ist das noch nicht im Git. Zum Testen hänge ich das hier mal mit an.

Die Syntax sieht dann so aus:

./hex2eq3.php --inFile <infile.hex> [--outFile <outfile>] [--spmPageSize <64|128|256|512>] [--hexEndAddress <hexEndAddress>] [--outFormat <eq3|hex|bin>] [--withCrcCheck --pathTo-srec_cat <pathTo-srec_cat>]

Wenn pathTo-srec_cat nicht angegeben ist wird das aktuell unter ./bin/srecord/srec_cat erwartet.


Übrigens: Franz hat das FW-Update auf seiner LXCCU mit dem neuen LAN-GW mit dem geänderten Bootloader auch schon erfolgreich testen können.
Somit scheint meine Erweiterung hier zu funktionieren.
Das ganze soll aber noch mal auf einer "Echten" CCU2 getestet werden. Wenn das da auch funktioniert dann können wir die die neue Version glaube frei geben.

Gruß
Dirk

[cactus-online]

...

Übrigens: Franz hat das FW-Update auf seiner LXCCU mit dem neuen LAN-GW mit dem geänderten Bootloader auch schon erfolgreich testen können.
Somit scheint meine Erweiterung hier zu funktionieren.
Das ganze soll aber noch mal auf einer "Echten" CCU2 getestet werden. Wenn das da auch funktioniert dann können wir die die neue Version glaube frei geben.

Gruß
Dirk

Eine echte CCU2 habe ich, aber keinen LAN-Adapter (wozu auch ?). Sag' was ich tun soll, dann probiere ich das aus.

[Dirk]

Eine echte CCU2 habe ich, aber keinen LAN-Adapter (wozu auch ?). Sag' was ich tun soll, dann probiere ich das aus.

Du musst den neuen Bootloader Flashen.
Dazu brauchst du einen ISP-Adapter oder einen Raspberry Pi, oder einen Arduino der dann dafür eine spezielle Firmware bekommt. den du z.B. über USB an den Rechner anschließen kannst.

Einen fertig kompilierten Bootloader auch mit deiner Seriennummer und HM-ID kann ich dir schicken.

[cactus-online]

OK. Leider warte ich ja noch auf den angekündigten Programmieradapter, ohne den geht es wohl nicht, richtig ?

[Dirk]

Wie gesagt, auch ein Raspberry Pi oder ein Arduino kann man vorübergehend zu einem Programmieradapter machen.
Falls du auf eine dieser Optionen Zugriff hast, können wir hier weiter machen.

Gruß
Dirk

[cactus-online]

Ich möchte nicht auf dem HM_LC_Sw1PBU_FM herumlöten. Vielleicht kann ich ja Deinen Temperatur-Sensor stattdessen zum Test verwenden ?

[Mr. P]

Also ich hatte für heute Abend geplant, einen "frischen" Schalter zu flashen.
Wenn also irgendein neuer Bootloader und/oder Firmware getestet werden soll - dann am besten gleich her damit.

[frank]

hallo unimatrix,

Habe eine Version fertig, mit der sich der Bootloader selbst flashen kann. Das ganze ist noch im Teststadium und ich habe es nur auf dem 644a getestet.

Wer mit testen möchte, findet das ganze auf meinem Fork: https://github.com/unimatrix27/Asksin_OTA_Bootloader

Sobald alle Feinschliffe und Tests gemacht sind, kann das ganze ggf. als deaktivierbare Option in die offizielle Version.

Freue mich über Feedback

ich habe deinen bootloader über isp geflasht. die applikation (firmware) kann ich anschliessend ota flashen und nutzen. dann habe ich den aktuellen bootloader von dirk mit eigener seriennummer und hmid gebaut und nach deiner anleitung ein eq3 file erzeugt. der flashvorgang ist laut eq3-sw erfolgreichgewesen. der bootloader der sich nun auf dem schalter meldet, sendet folgende message:

Code Auswählen Erweitern

2014.10.13 01:39:22.341 4: CUL_Parse: cul868 A 14 00 0010 FFFFFF 000000 00FFFFFFFFFFFFFFFFFFFF2C -52


seriennummer und hmid sind natürlich völlig falsch. aber zumindestens meldet sich ein bootloader. nur welcher? kann es sein, dass die kombination mit dem aktuellen bootloader von dirk die ursache ist? oder ist eventuell in der beschreibung deines bootloaders mit den srec-anweisungen etwas nicht ganz in ordnung?

wäre schön, wenn man dieses feature zum laufen bringen und in die offizielle bootloader-version einbauen könnte.

gruss frank

[Dirk]

Ich möchte nicht auf dem HM_LC_Sw1PBU_FM herumlöten. Vielleicht kann ich ja Deinen Temperatur-Sensor stattdessen zum Test verwenden ?

Ja klar. Mach das.

Also ich hatte für heute Abend geplant, einen "frischen" Schalter zu flashen.
Wenn also irgendein neuer Bootloader und/oder Firmware getestet werden soll - dann am besten gleich her damit.

Der aktuelle Stand ist bei mir im Github. Damit kannst du schon mal testen.
Ich denke aber, dass ich heute oder morgen Abend noch mal ein paar Änderungen nachreichen werde.

[Mr. P]

Der aktuelle Stand ist bei mir im Github. Damit kannst du schon mal testen.
Ich denke aber, dass ich heute oder morgen Abend noch mal ein paar Änderungen nachreichen werde.

Hej Dirk,

hab zwar gestern angefangen, bin dann aber nicht ganz fertig geworden - wenn es sich also heute bei dir noch ausginge, wäre das klasse (bin ohnehin nicht vor 23 Uhr daheim). Ansonsten eine kurze Info, dass es heute nichts mehr wird, dann kann ich auch noch problemlos bis morgen warten.

Thx a lot!

[frank]

hallo dirk,

Hast du die Bootloaderversion von Unimatrix die sich selber updaten kann drauf?
Funktioniert das zuverlässig? Vielleicht können wir die Versionen dann ja mal zusammenführen.

das ota-update des bootloaders hat jetzt perfekt funktioniert. bestätigen kann ich die 8k-variante mit dem hm-lc-sw1pbu-fm. wenn ich mir 2 bootloader mit unterschiedlicher seriennummer, jeweils mit dem vollständigen fileset von unimatrix, baue, gibt es keine probleme. egal ob mit oder ohne zusätzliche firmware. nach jedem flashen der firmware auch den schalter in fhem mit getconfig und regset probiert.

anschliessend wollte ich noch deinen wettersensor probieren. doch hier bekomme ich das hex-file des bootloaders nicht über isp mit avrdude geflasht. das flashen wird immer beendet mit:

Code Auswählen Erweitern

avrdude: ERROR: address 0x800a out of range at line 212 of Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex

beim bauen gab es auch schon vorher probleme mit der grösse des bootloaders, die ich aber durch abschalten der debugausgabe umgehen konnte. der komplette log von make und avrdude ist hier:

Code Auswählen Erweitern

D:\Dokumente und Einstellungen\frank\Eigene Dateien\FHEM\thpl_0.12\bootloader v0
.8.0-master\Asksin_OTA_Bootloader>make clean HB_UW_Sen_THPL
rm -rf *.o *.elf *.lst *.map *.sym *.lss *.eep *.srec *.bin *.hex \
        uart/*.o uart/*.elf uart/*.lst uart/*.map uart/*.sym uart/*.lss uart/*.e
ep uart/*.srec uart/*.bin uart/*.hex
make -C ./uart/ MCU=atmega328p
make[1]: Entering directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien
/FHEM/thpl_0.12/bootloader v0.8.0-master/Asksin_OTA_Bootloader/uart'

-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling: test_uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=test_uart.lst  -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -
o test_uart.o

Compiling: uart.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-ch
ar -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -W
a,-adhlns=uart.lst  -std=gnu99 -MD -MP -MF .dep/uart.o.d uart.c -o uart.o

Linking: test_uart.elf
avr-gcc -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-
adhlns=test_uart.o  -std=gnu99 -MD -MP -MF .dep/test_uart.elf.d test_uart.o uart
.o --output test_uart.elf -Wl,-Map=test_uart.map,--cref    -lm

Creating load file for Flash: test_uart.hex
avr-objcopy -O ihex -R .eeprom test_uart.elf test_uart.hex

Creating load file for EEPROM: test_uart.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 -O ihex test_uart.elf test_uart.eep
e:\programme\WinAVR-20100110\bin\avr-objcopy.exe: --change-section-lma .eeprom=0
x00000000 never used

Creating Extended Listing: test_uart.lss
avr-objdump -h -S test_uart.elf > test_uart.lss

Creating Symbol Table: test_uart.sym
avr-nm -n test_uart.elf > test_uart.sym
-------- end --------

make[1]: Leaving directory `D:/Dokumente und Einstellungen/frank/Eigene Dateien/
FHEM/thpl_0.12/bootloader v0.8.0-master/Asksin_OTA_Bootloader/uart'
avr-gcc -Wall -c -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressData=0x7F70,--section-start=.boot1=0x7F80     -DF_CPU=800000
0 -DHB_UW_Sen_THPL -Os cc.c -o cc.o
avr-gcc -Wall    -std=c99 -mmcu=atmega328p -Wl,--section-start=.text=0x7000,--se
ction-start=.addressData=0x7F70,--section-start=.boot1=0x7F80     -DF_CPU=800000
0 -DHB_UW_Sen_THPL -DBOOTLOADER_START=0x7000 -DBOOT_PAGES=31 -DCODE_LEN=0x6FFE -
Os bootloader.c cc.o uart/uart.o -o Bootloader-AskSin-OTA-HB_UW_Sen_THPL.elf
avr-objcopy -j .text -j .data -j .addressData -j .boot1 -O ihex Bootloader-AskSi
n-OTA-HB_UW_Sen_THPL.elf Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex
avr-size -C --mcu=atmega328p Bootloader-AskSin-OTA-HB_UW_Sen_THPL.elf
AVR Memory Usage
----------------
Device: atmega328p

Program:    3226 bytes (9.8% Full)
(.text + .data + .bootloader)

Data:        152 bytes (7.4% Full)
(.data + .bss + .noinit)

D:\Dokumente und Einstellungen\frank\Eigene Dateien\FHEM\thpl_0.12\bootloader v0
.8.0-master\Asksin_OTA_Bootloader>avrdude -p m328p -P \\.\com62 -b 19200 -c avri
sp -V -U flash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex auto detected as In
tel Hex
avrdude: ERROR: address 0x800a out of range at line 212 of Bootloader-AskSin-OTA
-HB_UW_Sen_THPL.hex
avrdude: write to file 'Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex' failed

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

wenn wir das noch erfolgreich testen, könnte man die bootloader-versionen doch eigentlich zusammenführen.

gruss frank