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

[Dirk]

Es war doch  noch ein kleiner Bug in updateBootloaderFromRWW.
boot_rww_enable darf erst am ende kommen.
sonst wird die Page mit dem magicWord nicht gelöscht.

Ist gefixt und im Github.

[frank]

hallo dirk,

danke für den neuen bootloader. der läuft bei mir gerade auf dem schalter in der 8k-version. das anschliessende ota update mit meiner alten eq3 firmware hat auch funktioniert. beim ersten mal hat eq3 ein erfolgreiches update gemeldet, aber der bootloader hat es wohl nicht akzeptiert. der 2 versuch war dann ok.

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.

nun möchte ich mir eq3-files bauen und wollte das neue hex2eq3-script probieren. da stehe ich noch ein wenig auf dem schlauch.

Code Auswählen Erweitern

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

1.  [--outFile <outfile>] sehe ich das richtig, dass wenn ich hier zb "<file>.eq3" angebe, der parameter [--outFormat <eq3|hex|bin>] entfallen kann?

2. [--spmPageSize <64|128|256|512>] ist hier 128 default?

3. [--hexEndAddress <hexEndAddress>] welcher wert ist das genau? 0xFFFF für bootloader? fehlt eventuell noch ein parameter, um 4k/8k unterscheiden zu können? im php-script gibt es ein wert 0x6FFE. das wäre dann also CODE_END (aus makefile) - 1 byte. 

5. [--withCrcCheck] ist das jetzt nicht eigentlich abgeschaft, oder muss das doch noch angegeben sein?

gruss frank

[Dirk]

nun möchte ich mir eq3-files bauen und wollte das neue hex2eq3-script probieren. da stehe ich noch ein wenig auf dem schlauch.
1.  [--outFile <outfile>] sehe ich das richtig, dass wenn ich hier zb "<file>.eq3" angebe, der parameter [--outFormat <eq3|hex|bin>] entfallen kann?

outfile ist nur der Dateiname daraus wird nicht auf den Typ geschlossen. Somit musst du als outFormat  dann eq3 angeben.

2. [--spmPageSize <64|128|256|512>] ist hier 128 default?

Nein. spmPageSize muss auch angegeben werden ein Default gibt es nicht. Ok, der sollte noch mit rein.

3. [--hexEndAddress <hexEndAddress>] welcher wert ist das genau? 0xFFFF für bootloader?

Das ist die Endadresse des Application-Bereiches. Defaut ist 0x6FFE. Diese ist abhängig vom AVR und von der Bootloadergröße.
Eigentlich sollte hier der Wert "CODE_END" aus dem entsprechenden Makefile-Abschnitt angegeben werden. Aktuell muss hier aber CODE_END-1 angegeben werden.

5. [--withCrcCheck] ist das jetzt nicht eigentlich abgeschaft, oder muss das doch noch angegeben sein?

withCrcCheck muss gesetzt sein. Denn der Bootloader akzeptiert keine Updates mehr ohne CRC. Das ist aktuell nur noch drin geblieben um auch Updatefiles ohne CRC zu erstellen. Vermutlich kann das aber auch raus.

Ok, ich sehe schon, hier sind noch ein paar "Kleinigkeiten" zu lösen.
Eigentlich hätte ich das Script auch gerne so umgebaut damit es auch ohne srec-cat auskommt.
Auch würde ich das gerne noch auf Perl portieren. Das Php-Script ging aber schneller

Update:
Es muss natürlich "CODE_END-1" heisen

[frank]

das ist ja alles nicht so einfach. 

meine windows xp eingabeaufforderung (dos-fenster) sagt nun:

Code Auswählen Erweitern

D:\Dokumente und Einstellungen\frank\Eigene Dateien\FHEM\thpl_0.12\Asksin_OTA_Bo
otloader v0.7.0>php contrib\hex2eq3.php --inFile Bootloader-AskSin-OTA-HM_LC_Sw1
PBU_FM_8k.hex --outFile Bootloader-AskSin-OTA-HM_LC_Sw1PBU_FM_8k --spmPageSize 2
56 --hexEndAddress 0xDFFE --outFormat eq3 --markAsBootloaderUpdate --withCrcChec
k
Der Befehl "D:\Dokumente" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Der Befehl "D:\Dokumente" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
Could not open tmpfile.tmp

irgendwer kommt nun nicht mit den langen namen nicht klar, denk ich. wobei bin2eq3.php immer gut funktioniert hat.

Das ist die Endadresse des Application-Bereiches. Defaut ist 0x6FFE. Diese ist abhängig vom AVR und von der Bootloadergröße.
Eigentlich sollte hier der Wert "CODE_END" aus dem entsprechenden Makefile-Abschnitt angegeben werden. Aktuell muss hier aber CODE_END-2 angegeben werden.

hm... CODE_END ist aber mit 0x6FFF angegeben. mit "CODE_END-2" komme ich da dann auf 0x6FFD. du meintest vielleicht "BOOTLOADER_START (0x7000) -2"?

könnte nicht das makefile neben dem hex-file gleich noch ein eq3-file auswerfen? da sind doch eigentlich schon alle infos beisammen.

gruss frank

[Dirk]

meine windows xp eingabeaufforderung (dos-fenster) sagt nun:

Ah Windows. Hast du eine srec-cat Version von Windows. Ansonsten wird das nicht funktionieren.

irgendwer kommt nun nicht mit den langen namen nicht klar, denk ich.

Das Problem ist hier nicht der lange Name sondern die Leerzeichen im Pfad.
Kopier das Script mal in eine in Pfad ohne Leerzeichen.
Aber wie gesagt, ohne eine Windows-Version von srec-cat funktioniert das so noch nicht.

hm... CODE_END ist aber mit 0x6FFF angegeben. mit "CODE_END-2" komme ich da dann auf 0x6FFD.

Äh, stimmt ich meine natürlich "CODE_END-1" Ich habe es untern gleich mal geändert.

könnte nicht das makefile neben dem hex-file gleich noch ein eq3-file auswerfen? da sind doch eigentlich schon alle infos beisammen.

Nicht wenn man ein "fremdes" Firmware-File so konvertieren will.

[frank]

Ah Windows. Hast du eine srec-cat Version von Windows. Ansonsten wird das nicht funktionieren.

ist sogar bei winavr und arduino ide dabei. hatte mir aber eine neuere version beschaffen müssen, da wir so exotische optionen nutzen. die hatte ich dann bei winavr ausgetauscht, womit windows den pfad eigentlich immer kannte. beim script musste ich jetzt alles angeben, damit es funktionierte.

Kopier das Script mal in eine in Pfad ohne Leerzeichen.

das hat dann wunderbar geklappt.

das ota update mit eq3-file will aber nicht. mit folgendem befehl habe ich es für den wettersensor erzeugt.

Code Auswählen Erweitern

E:\downloads\thpl_0.12\Asksin_OTA_Bootloader_0.7.0>php contrib\hex2eq3.php --inF
ile Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex --outFile Bootloader-AskSin-OTA-HB_
UW_Sen_THPL.eq3 --spmPageSize 128 --hexEndAddress 0x6FFE --outFormat eq3 --markA
sBootloaderUpdate --withCrcCheck --pathTo-srec_cat e:\programme\srecord-1.64-win
32\srec_cat.exe

Achja, und vor dem Bootloader-Update blinkt die LED jetzt auch 10mal schnell. So dass man den Start des Updates auch optisch erkennen kann.

das geschieht auch, aber der bootloader meldet sich immer noch mit den selben devicedaten (hmid, sn), sodass das eq3-tool dann sofort wieder neu startet. also ist entweder das 10-fache blinken falsch oder die neuen daten gehen verloren.

update: gleiches verhalten beim schalter mit 8k-version.

gruss frank

[Dirk]

das geschieht auch, aber der bootloader meldet sich immer noch mit den selben devicedaten (hmid, sn)

Das ist so auch erstmal korrekt so.
Die Devicedaten befinden sich noch hinter der Updateroutine im Flash. also in den letzten 16 Bytes.
Diese Daten kann man per OTA-Update durch einen neuen Bootloader nicht ändern.
Das geht nur initial per ISP.

Das mach so ja auch sinn. Denn dann kann man einen "allgemeinen" Bootloader für Updates verteilen.

sodass das eq3-tool dann sofort wieder neu startet. also ist entweder das 10-fache blinken falsch oder die neuen daten gehen verloren.

Das ist ein Problem mit dem eq3-tool.
Wenn du den Bootloader updatest dann wird der Programmcode gelöscht.
Nach dem Bootloaderupdate ist der Sensor also wieder leer. Der Bootloader möchte dann automatisch wieder weiter flaschen.

Das eq3-tool stoppt nach dem Update aber nicht, sondern liefert die aktuell eingestellte Software soffort wieder an einen sich meldenden Bootloader aus.
Wenn das eq3-tool den Updatevorgang also als "fertig" gemeldet hat, dann muss man manuell auf abrechen drücken. Sonst landet man in einer Flash-Schleife.
Das ist ziemlich dämlich da umgesetzt.

Gruß
Dirk

[frank]

Das mach so ja auch sinn. Denn dann kann man einen "allgemeinen" Bootloader für Updates verteilen.

genial.    ein erfolgreiches update kann man dann also nur am 10-fachen blinken erkennen.

dann ist ja alles perfekt und der schalter kann endlich eingemauert werden. 
danke vielmals, auch an alle anderen bootloader-entwickler. jetzt ist bei eq3 wohl urlaubssperre, damit sie hinterherkommen.

gruss frank

[Dirk]

ein erfolgreiches update kann man dann also nur am 10-fachen blinken erkennen.

Du kannst im neuen Bootloader ja z.B. das Blinken der LED verändern. Dann solltest du das nach dem Flashen sehen können.

Wir können ja die Versionsnummer im Blinken der LED kodieren. Version 0.7.1 würde dann z.B. so aussehen: 0 mal lang - 7 mal kurz - einmal lang
Wobei die Idee ist vielleicht gar nicht so verkehrt.

dann ist ja alles perfekt und der schalter kann endlich eingemauert werden.

Vielleicht wartest du noch ein paar Tage bis noch bei ein paar anderen Testern alles ok ist

[frank]

Wobei die Idee ist vielleicht gar nicht so verkehrt.

prima idee. 

[Dirk]

prima idee. 

Ich habs mal eingebaut.
Man kann das im device .c file ein / oder ausschalten

[frank]

Also solange die 4k genügen und beide Devices damit bedient werden können, gibt es wohl kaum einen Grund, die 8k-Variante nutzen zu wollen.

ich sehe das im augenblick so: der schalter hat 64k flash, die vermutlich nie genutzt werden. somit gibt es in absehbarer zukunft keinen grund den bootloaderbereich möglichst klein zu halten. der augenblickliche code des bootloaders benötigt knapp 4k. nach und nach hat dirk den code immer wieder schlanker gemacht, um neue features noch hinein zu bringen. es wird also immer enger. somit gönne ich meinem schalter lieber 8k bootloaderbereich, damit ich immer alle features zukünftiger bootloader versionen nutzen kann. denn zu jeder bootloader-grössenveränderung müssen die fusebits verändert werden und das bedeutet ausbauen, löten und über isp flashen. in der neuen ära des ota-updatebaren ota-bootloaders soll das bei mir der vergangenheit angehören. 

Auf die Gefahr hin, dass ich in meinem übermüdeten Zustand etwas überlesen habe... aber könntest du die funktionierenden Workflows mit der zuletzt getesteten Version für Schalter und Sensor posten?

1. dirks bootloader-umgebung clonen/downloaden https://github.com/kc-GitHub/Asksin_OTA_Bootloader

2. devicedaten deines schalters (sn, hmid) in devices/HM-LC-Sw1PBU-FM.h mit den originaldaten ersetzen und typ=0xF0A9 setzen (modelnummer des schalters mit alternativer firmware). damit sind die daten im flash verewigt und du brauchst dich eigentlich nicht mehr darum zu kümmern. bei einem nächsten bootloader update kannst du ein beliebiges bootloader_8k.eq3 file ota flashen. trotzdem behält der bootloader seine daten. theoretisch sollte das auch mit firmwaredateien funktionieren. bei der schalterfirmware ist es eventuell aber noch nicht integriert. beim wettersensor funktioniert es aber bereits.

3. bootloader bauen (8k):

Code Auswählen Erweitern

make clean HM_LC_Sw1PBU_FM_8k

4. fusebits setzen (8k, unlock):

Code Auswählen Erweitern

avrdude -p m644 -P usb -c usbasp -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m -U lock:w:0x3F:m

5. über isp flashen (8k):

Code Auswählen Erweitern

avrdude -p m644 -P usb -c usbasp -V -U flash:w:Bootloader-AskSin-OTA-HM_LC_Sw1PBU_FM_8k.hex

6. fertig

wenn dann in den nächsten wochen die neue version mit flashen über fhem erscheint, einfach ein neues hexfile bauen und mit dem tool hex2eq3.php daraus ein eq3-file erstellen. zb bei mir für den schalter (8k):

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

eventuell werden dann sogar schon fertige eq3-files angeboten, die du dann in deinem eq3-firmware-update-thread aufnehmen kannst. dann bräuchtest du gar nichts mehr bauen, sondern nur noch ota-flashen.    weitere einzelheiten in der readme.md. wahrscheinlich noch nicht ganz auf dem neuesten stand.

gruss frank

[Mr. P]

es wird also immer enger. somit gönne ich meinem schalter lieber 8k bootloaderbereich, damit ich immer alle features zukünftiger bootloader versionen nutzen kann.

Hej frank,

zuerst einmal Danke für die ausführliche Anleitung. Damit dürfte alles klar sein.

Die 4k Version hätte ich deshalb präferiert, da wohl irgendwann auch Schluss mit neuen Bootloaderversionen sein wird und ich mir gut vorstellen kann, dass Dirk es gerne hätte, wenn nicht unterschiedliche Bootloaderversionen für Wettersensor und Schalter verwendet werden müssen (und wenn auch nur einzelne Features vor dem Kompilieren aktiviert bzw. deaktiviert werden müssen). Aber natürlich, wenn es nur um den Schalter geht (und um den gehts hier im Thread) bist du mit 8k du auf alle Fälle auf der sicheren Seite und musst dir keine Gedanken machen, ob eine Version des Bootloaders nicht vielleicht doch einmal mehr als 4k brauchen könnte.

[Dirk]

So, es waren doch noch ein Paar Schusselfehler drin:

• Das Update über die CCU war wieder "kaput". Ist aber wieder gefixt und wurde nun auch getestet.
• Der Blinkcode der LED mit der Versionsnummer kommt jetzt nur noch nach einen PowerOn reset. Aber nicht wenn beim Einschalten die Configtaste gedrückt wird. Der Bootloader also erzwungen gestartet werden soll.
• Es wurde eine Page vom Bootloaderupdate vergessen zu schreiben
• Im Flashtool wurde beim Flashen ein falsches Lockbit gesetzt. Hier wurde der Bootloaderbereich geschützt. Das bringt natürlich nichts wenn man den Bootloader updaten möchte.

Ich hoffe damit sind alle Bugs behoben. Und hoffe auf reges testen

und ich mir gut vorstellen kann, dass Dirk es gerne hätte, wenn nicht unterschiedliche Bootloaderversionen für Wettersensor und Schalter verwendet werden müssen (und wenn auch nur einzelne Features vor dem Kompilieren aktiviert bzw. deaktiviert werden müssen).

Naja, Im Moment haben alle Versionen des Loaders noch die selben Einstellungen. Somit kann jeder selber entscheiden ob er den 4k oder 8k Loader nehmen möchte.
Wenn man aber genug Platz im Flash hat, kann man trotzdem den 8k Bootloader benutzen. Dann ist ein bisschen Platz falls man noch andere Sachen machen möchte.
Z.B. falls man doch noch eine Verschlüsselung einbauen möchte o.Ä.

Gruß
Dirk

[frank]

So, es waren doch noch ein Paar Schusselfehler drin:
...
Es wurde eine Page vom Bootloaderupdate vergessen zu schreiben

betrifft das auch den minibootloader? muss also zwangsläufig über isp geflasht werden oder reicht hierfür ein ota-update?

gruss frank