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

[nephdrasil]

Hallo Leute bekomme beim bauen des Bootloaders auf dem PI folgenden Fehler,

Code Auswählen Erweitern

-------- begin --------
avr-gcc (GCC) 4.7.2
Copyright (C) 2012 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=atmega644 -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=test_uart.lst  -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -o test_uart.o
test_uart.c:12:20: fatal error: stdlib.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
makefile:458: recipe for target 'test_uart.o' failed
make[1]: *** [test_uart.o] Error 1
make[1]: Leaving directory '/home/pi/Asksin_OTA_Bootloader/uart'
Makefile:86: recipe for target 'uart_code' failed
make: *** [uart_code] Error 2

Könnt ihr mir Helfen.

[Tobias]

und noch ein Hilfesuchender:

Code Auswählen Erweitern

root@Iconnect:~/HM-LC-SW1PBU-FM# srec_cat LEQ1293815.hex -intel -fill 0xFF 0x0000 0xEFFE -Cyclic_Redundancy_Check_16_Little_Endian 0xEFFE -o LEQ1293815.hex -binary
unknown "-Cyclic_Redundancy_Check_16_Little_Endian" option

Nach dem Bootloader-Bauen und flashen auf dem Schalter sowie OTA-Flash per flash-ota mit einer avr-objcopy erstellten bin -> eq3 Datei, befindet sich der Bootloader in einer endlosschleife:
1x lang blinken
2x sehr kurz blinken
Pause ca 8sek

Also denke ich, das ich die FW mit CRC Check uploaden muss. Korrekt? Aber leider kennt dieser obigen Parameter nicht....

Edit: Wenn ich die eq3-Firmware von hier meldet  flash-ota auch "ok", aber auch hier bleibt der Bootloader in einer Endlosschleife hägen.
Habe ich am Bootloader bauen etwas falsch gemacht?

1) in devices/HM_LC_Sw1PBU_FM.h habe ich meine Serial und HMID eingetragen
2) make HM_LC_Sw1PBU_FM ausgeführt
3) avrdude -p m644 -c stk500v2 -P /dev/ttyUSB0 -U lfuse:w:0xFD:m -U hfuse:w:0xDA:m -U lock:w:0x2F:m
4) per USB-Programmer den schalter geflashed
5) ./flash-ota -f firmware_HM-LC-Sw1PBU-FM.eq3 -s LEQ1293815 -c /dev/ttyACM0

Code Auswählen Erweitern

root@Iconnect:~/HM-LC-SW1PBU-FM# ./flash-ota -f firmware_HM-LC-Sw1PBU-FM.eq3 -s LEQ1293815 -c /dev/ttyACM0
HomeMatic OTA flasher version 0.097-git

Reading firmware from firmware_HM-LC-Sw1PBU-FM.eq3...
Firmware with 77 blocks successfully read.
Opening culfw-device at path /dev/ttyACM0 with speed 38400
Requesting firmware-version
culfw-device firmware version: 1.63
Entering 10k-mode
Waiting for device with serial LEQ1293815
Device with serial LEQ1293815 (hmid: 341c88) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 77 blocks: 0001/0077 /
Missing ACK!
Flashing 77 blocks: 0002/0077 /
Missing ACK!
Flashing 77 blocks: 0002/0077 /
Missing ACK!
Flashing 77 blocks: 0008/0077 /
Missing ACK!
Flashing 77 blocks: 0013/0077 /
Missing ACK!
Flashing 77 blocks: 0018/0077 /
Missing ACK!
Flashing 77 blocks: 0023/0077 /
Missing ACK!
Flashing 77 blocks: 0024/0077 /
Missing ACK!
Flashing 77 blocks: 0046/0077 /
Missing ACK!
Flashing 77 blocks: 0050/0077 /
Missing ACK!
Flashing 77 blocks: 0060/0077 /
Missing ACK!
Flashing 77 blocks: 0077/0077 -
Entering 10k-mode
Waiting for device to reboot
root@Iconnect:~/HM-LC-SW1PBU-FM#
 

Auch habe ich in bootloader.c nichts passendes gefunden, um diesen CRC Check abzuschalten, dafür fehlt mir das KnowHow

[frank]

dein bootloader findet keine oder keine korrekte fw, daher sendet er nun regelmaessig die anlernmessage zum weiteren flashen. der crc-modus wird durch define festgelegt. ich denke, default ist on. kann gerade nicht nachschauen. wenn du keinen schreibfehler hast, ist dein srec_cat wohl zu alt und kennt die option nicht.

[Tobias]

supi, danke!!!

aktuelles srecord package neu kompiliert und sofort hat es funktioniert
Jetzt startet mein Bootloader auch sauber die FW

Hast du noch einen  Hinweis, wie und wo man im BL-Code den CRC Check ausschaltet??

[frank]

Hast du noch einen  Hinweis, wie und wo man im BL-Code den CRC Check ausschaltet??

sorry, da hatte ich wohl zuviel versprochen, ist mittlerweile pflicht.
warum wolltest du das überhaupt abschalten?

Es sei denn jemand möchte was größeres anstellen und braucht die zusätzlichen 4k noch 

Ich habe jetzt auch ein paar Tests gemacht und das Bootloaderupdate für gut befunden
Ich habe alles bei mir im Github eingecheckt.

Folgende Sachen sind noch hier dazu gekomen:

• Compatibilität mit dem Update durch die CCU: Die CCU folgt ja nicht dem "normalen" Hochzählen des Message-ID. In meinem Fall habe ich Steps von 8. Da hier andere "Sprünge" nicht ausgeschlossen sind, habe ich den Check der Message-ID noch etwas geändert. Der Bootloader prüft jetzt nur noch ob das folgende Packet eine höhere MessageId hat. Der abschliessende Test an der CCU steht aber noch aus.
• Der CRC-Check ist nun "Pflicht". Ich habe die vorherigen Defines wo der CRC-Check abgeschaltet werden konnte entfernt. Ich meine ein Firmwareupdate ohne CRC-Prüfung macht keinen Sinn. Vor allem wenn so auch der Bootloader upgedatet werden kann.
  Allerdings ist der aktuell implementierte CRC16 für 32k bzw. 64k Daten nicht wirklich ausreichend. Daher werde ich wohl die Tage versuchen noch den CRC-Check auf CRC32 umzustellen.
  
• Das Makefile gibt jetzt auch Auskunft über die detailierte Speicherausnutzung
• Das hex2eq3-Tool kann auch ein Update als Bootloader-Update "Flaggen". So muss man das sreg-cat Kommando nicht selber zusammenschreiben.
• Achja, und vor dem Bootloader-Update blinkt die LED jetzt auch 10mal schnell. So dass man den Start des Updates auch optisch erkennen kann.

Ich habe dem Bootloader jetzt die Version 0.7.0 gegeben.
@Unimax: 0.8.0 fand ich dann doch etwas zu viel

Viele Grüße
Dirk

[frank]

Hallo Leute bekomme beim bauen des Bootloaders auf dem PI folgenden Fehler,

Code Auswählen Erweitern

-------- begin --------
avr-gcc (GCC) 4.7.2
Copyright (C) 2012 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=atmega644 -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=test_uart.lst  -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -o test_uart.o
test_uart.c:12:20: fatal error: stdlib.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
makefile:458: recipe for target 'test_uart.o' failed
make[1]: *** [test_uart.o] Error 1
make[1]: Leaving directory '/home/pi/Asksin_OTA_Bootloader/uart'
Makefile:86: recipe for target 'uart_code' failed
make: *** [uart_code] Error 2

Könnt ihr mir Helfen.

Code Auswählen Erweitern

fatal error: stdlib.h: Datei oder Verzeichnis nicht gefunden
ich bin in windows unterwegs. deshalb rate ich mal.
ich denke stdlib.h sollte vom compiler kommen. ist der pfad von gcc korrekt? daterechte ok?

[Tobias]

wie ist denn der korrekte Aufruf von hex2bin.php für einen 4k Bootloader? zb. spmPageSize

Da im Booloader auch schon Serial und HMID drin ist, unterstützt die neuste FW schon das "ausnullen" und holt sich beides somit aus dem BL?
Edit: gerade gesehen, im Wettersensor schon integrieert, hier aber noch nicht...

[frank]

wie ist denn der korrekte Aufruf von hex2bin.php für einen 4k Bootloader? zb. spmPageSize

ich sehe gerade nicht, wozu hex2bin noch gebraucht wird. das war, glaub ich, nur für den fall ohne srec_cat. jetzt muss man nur wie hier https://github.com/jabdoa2/Asksin_OTA_Bootloader verfahren. für 4k folgt:

1.

Code Auswählen Erweitern

make clean HM_LC_Sw1PBU_FM
hiermit baust du dir das hex-file.

2.

Code Auswählen Erweitern

srec_cat <payload.hex> -intel -fill 0xFF 0x0000 0x6FFE -Cyclic_Redundancy_Check_16_Little_Endian 0x6FFE -o  payload.bin -binary
mit srec_cat machst du aus dem hex ein bin-file, um dieses anschliessend in eq3 zu verwandeln:

3.

Code Auswählen Erweitern

./bin2eq3.php payload.bin payload.eq3 # convert to eq3 hex format

Dependent on the flash page size of the desired AVR, a different page size can pass as third parameter in bytes. The default pages size is 256 bytes.
E.g. the Atmega328 needs a page size of 128 bytes.
für den schalter brauchst du kein pagesize angeben, da bereits default 256. ist prozessorabhängig.

zusätzlich hat dirk ein tool hex2eq3 (im contrib ordner) gebaut um 2. und 3. in einem rutsch zu machen. für meine 8k variante für ein bootloader-eq3 verwende ich den aufruf:

Code Auswählen Erweitern

php contrib\hex2eq3.php --inFile Bootloader-AskSin-OTA-HM_LC_Sw1PBU_FM_8k.hex --outFile Bootloader-AskSin-OTA-HM_LC_Sw1PBU_FM_8k.eq3 --spmPageSize 256 --hexEndAddress 0xDFFE --outFormat eq3 --markAsBootloaderUpdate --withCrcCheck --pathTo-srec_cat e:\programme\srecord-1.64-win32\srec_cat.exe

[Tobias]

sorry für den Versprecher, jetzt korrekt:
wie ist denn der korrekte Aufruf von hex2eq3.php für einen 4k Bootloader?

Habe mal das Wiki wieder aktualisiert

Edit: @frank: du schreibst: --inFile Bootloader-AskSin-OTA-HM_LC_Sw1PBU_FM_8k.hex
flashst du damit den Bootloader ota oder die FW? Sind die Parameter für die FW anders, zb. hexEndAddress ?

Kannst du bitte mal den Wikiartikel prüfen?? http://www.fhemwiki.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware#Firmware_OTA_flashen

[frank]

http://forum.fhem.de/index.php/topic,18071.msg208489.html#msg208489
hier erklärt mir dirk das hex2eq3.

du musst eigentlich nur die pfade und dateinamen anpassen und den wert hexEndAddress. der ist mit dem im srec_cat identisch. also für den schalter und 4k bootloader => 0x6FFE.

flashst du damit den Bootloader ota oder die FW?

wie geschrieben mit der option --markAsBootloaderUpdate den bootloader. ohne diese option die fw.

zum wiki:

ich denke, man sollte die struktur des wiki über das flashen ein wenig überarbeiten/entwirren.

grundsätzlich kann man ja bootloader und fw jeweils als eigenständige applikation sehen, die entweder gemeinsam oder getrennt auf dem schalter existieren. der bootloader hat natürlich sehr beschränkte funktionen. meine empfehlung wäre, grundsätzlich einen bootloader zu flashen, da dieser die möglichkeit bietet, ota-updates zu flashen. sowohl für einen neuen bootloader, als auch die eigentliche fw. der bootloader enthält im grunde einen mini-bootloader, der sich selber überschreiben kann. sofern sich an diesem mini-bootloader nichts ändert, können alle folgenden bootloader-updates immer ota geflasht werden. der grosse vorteil von ota ist, dass man nicht mehr löten muss.

beide applikationen benötigen seriennummer, hmid und modelID. ändert man nichts, werden defaultwerte benutzt. mit diesen daten meldet sich der bootloader beim ota-update. wenn dirk es nun schafft, der fw beizubringen, diese daten aus dem bootloader zu lesen, muss man dann nur noch einmal im bootloader diese daten eingeben, den bootloader bauen, löten und mit programmer flashen. also beim ersten bootloader auf jeden fall die daten einpflegen. desweiteren sollte man, finde ich, beim schalter grundsätzlich dem bootloader die 8k-speicher spendieren, um für jegliche bootloadererweiterungen gewappnet zu sein. die restlichen 56k sollten für die fw bis in alle ewigkeiten genügen. im augenblick sind 4k und 8k bootloader völlig identisch. es werden den versionen nur grössere bereiche zugewiesen. die 4k version ist eigentlich wegen dem wettersensor entstanden, da der prozessor dort nur maximal 4k bootloader zur verfügung hat. will man später von 4k auf 8k erhöhen, muss man wieder löten, um die fuses zu setzen.

ich würde also als erstes beschreiben, wie man mit avrdude/make den 8k bootloader mit den entsprechenden devicedaten auf den schalter flasht. als 2. den bau von eq3-files zum ota-update. einmal für den bootloader und einmal für die fw. die tar-files für das windows tool werden eigentlich auch nicht mehr benötigt, da das tool auch direkt die eq3-files flashen kann. eventuell sogar alle 4k-variationen entfernen. dann muss sich keiner mehr gedanken machen, wozu was gut ist. der text reduziert sich auf die hälfte und es passieren wahrscheinlich weniger fehler, da man immer den passenden befehl erwischt. falls wirklich mal einer (wahrscheinlich nie) einen 4k bootloader wirklich braucht, kann er das auch im git in erfahrung bringen. 4k hat zur zeit eigentlich nur nachteile. der code passt jetzt schon kaum noch rein.

der bootloader startet immer, wenn die netzspannung eingeschaltet wird, dabei wird nichts resettet. wenn auf dem schalter nur der bootloader vorhanden ist, versucht er permanent (ca 10 sek) ein ota-update zu machen. findet er eine korrekte fw, startet er diese. man muss also nur bei vorhandener fw, die konfigtaste bei netzspannungszufuhr gedrückt halten, damit das update starten kann. dadurch wird verhindert, dass der bootloader die vorhandene fw startet.

die hex2eq3 beispiele sind natürlich noch fehlerbehaftet. die cpp.hex files sind vom arduino? auch hier würde ich 4k entfernen.

gruss frank

[Tobias]

Habs im Wiki angepasst. Alles 4k ist raus und ein bissl umsortiert.

[Tobias]

Hi,
klappt alles super! Mit DeviceReset durch Strom-aus/Strom-an läuft das FWUpdate.

Was noch nicht klappt ist ein FW-Update ohne Stromunterbrechung.
Ich habe flash-ota gestartet und in FHEM ein Device Reset ausgelöst, mal mit gedrückter Configtaste, mal ohne. Leider passiert jeweils nix beim flash-ota.
Dann habe ich per FHEM ein fwUpdate gestartet, aber da kommt nur: fail:Block1

Jemand einen Hinweis wie der korrekte Weg ist?

[der2of6]

Hallo Leute bekomme beim bauen des Bootloaders auf dem PI folgenden Fehler,

Code Auswählen Erweitern

-------- begin --------
avr-gcc (GCC) 4.7.2



Compiling: test_uart.c
avr-gcc -c -mmcu=atmega644 -I. -gdwarf-2 -DF_CPU=8000000UL    -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=test_uart.lst  -std=gnu99 -MD -MP -MF .dep/test_uart.o.d test_uart.c -o test_uart.o
test_uart.c:12:20: fatal error: stdlib.h: Datei oder Verzeichnis nicht gefunden


Könnt ihr mir Helfen.

Hi,
Bei der Fehlermeldung fehlt dir noch eine libary auf dem Raspi.

Ich meinen leider nicht an der Hand, aber probiere mal folgendes noch zu installieren:

Code Auswählen Erweitern

apt-get install avr-libc

Ansonsten noch mal suchen, was alles zum avr-gcc noch angeboten wird

[frank]

Was noch nicht klappt ist ein FW-Update ohne Stromunterbrechung.

richtig, gibt es nicht.

Ich habe flash-ota gestartet und in FHEM ein Device Reset ausgelöst, mal mit gedrückter Configtaste, mal ohne. Leider passiert jeweils nix beim flash-ota.

das verstehe ich nicht. du schreibst vorher ein devicereset wäre strom an-/ausschalten.

der bootloader startet immer, wenn die netzspannung eingeschaltet wird, dabei wird nichts resettet. wenn auf dem schalter nur der bootloader vorhanden ist, versucht er permanent (ca 10 sek) ein ota-update zu machen. findet er eine korrekte fw, startet er diese. man muss also nur bei vorhandener fw, die konfigtaste bei netzspannungszufuhr gedrückt halten, damit das update starten kann. dadurch wird verhindert, dass der bootloader die vorhandene fw startet.

Dann habe ich per FHEM ein fwUpdate gestartet, aber da kommt nur: fail:Block1

der bootloader mag noch nicht mit fhem.

[Tobias]

HI FRank,
mit dem CustomFW.pm gibt es ein: "set <device> reset"
Ich hätte erwartet das dadurch im Schalter ein reboot durch die Applikation ausgelöst wird.
Ich habe hier gelesen (http://forum.fhem.de/index.php/topic,23329.msg166531.html#msg166531) das die Firmware ein Reboot auslösen kann wodurch der Bootloader wieder aktiviert wird wodurch man widerrum in der Lage ist eine neue FW/BL zu flashen (wenn(!) man die configtaste drückt). Aus desem Grund wurde IMHO ja die ConfigTaste involviert damit man als Angreifer nicht einfach eine neue FW aufspielen kann.

Mein Verständnis ist/war so, das ein "set <device> reset" einem "Strom an/Strom aus" gleichkommt.

Habe ich etwas falsch verstanden oder ist der verlinkte Thread schon veraltet und alles ist anders?