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

[DOCa Cola]

hm, ist es richtig, dass das mit srecord erzeugte file dann kleiner ist?

Code Auswählen Erweitern


srec_cat Asksin_HM_LC_Sw1PBU_FM.cpp.hex -intel -fill 0xFF 0x0000 0x6FFE -Cyclic_Redundancy_Check_16_Little_Endian 0x6FFE -o payload.bin -binary

Asksin_HM_LC_Sw1PBU_FM.cpp.hex - 57kb
payload.bin - 29kb

anyway, ich habe das file mal reingeladen (nachdem ich es mit bin2eq3 konvertiert habe), aber er scheint nicht wirklich weiterzukommen. Ich bekomme nach dem reboot, wie schon direkt nach dem flashen, sich wiederholendes LED blinken: lang, 1 sek pause, kurz, kurz, 10 sek pause...
wenn ich es richtig verstanden habe ist das der awaiting-firmware modus?

[Dirk]

Ich sags ja... Der Bootloader müsste OTA als "Hauptprogramm" in den Schalter geladen werden und wenn nach dem Reset die CRC-Prüfung passt, spielt er sich von selbst in die ersten 4k und startet abermals mit dem neuen Loader neu.

So hatte ich mir das auch schon mal überlegt. Bisher bin ich aber davon ausgegangen dass man aus der Program-Section kein SPM aufrufen kann?
müsste man mal probieren.

lang, 1 sek pause, kurz, kurz, 10 sek pause...

Die Reihenfolge ist etwas verschoben, ich versuche es trotzdem mal.

lang (ca. 2 Sek. bedeuted CRC-Check fail.
1 sek. Pause ist der Reboot. Weil lang kommt ganz zum Schluss.
kurz, ist der Start des bootloaders
das 2. kurz ist das warten auf Programmdaten via Funk.
10 sek. pause ist die Zeit die der BL auf die Daten wartet.

Da scheint der CRC-Check also nicht zu stimmen.
Schau doch mal ins Makefile ob ich die Adressen für den 644 richtig eingetragen habe.

[DOCa Cola]

Schau doch mal ins Makefile ob ich die Adressen für den 644 richtig eingetragen habe.

Das übersteigt ein wenig meine rudimentären Microcontroller Kenntnisse. Aus dem Datasheet werde ich auch nicht wirklich schlau. Oder wie kann ich das ermitteln?

[Dirk]

Das übersteigt ein wenig meine rudimentären Microcontroller Kenntnisse. Aus dem Datasheet werde ich auch nicht wirklich schlau. Oder wie kann ich das ermitteln?

Das ist eigentlich ganz einfach.
Die Checksumme wird in den letzten 2 Bytes von der Application-Section erwartet.
Bei den Fuse-Settings für einen 4k Bootloader-Bereich geht der Application-Bereich beim Atmega644 bis 64k-4k. Die Werte im Makefile errechnen sich so:

Code Auswählen Erweitern


CODE_LEN:           65536 (0x10000) - 4096 (0x1000) - 2 = 61438 (0xEFFE)
BOOTLOADER_START:   65536 (0x10000) - 4096 (0x1000)     = 61440 (0xF000)
ADDRESS_DATA_START: 65536 (0x10000) -   16   (0x10)     = 65520 (0xFFF0)


Sofern ich mich hier nicht verrechnet habe sollte das eigegentlich stimmen.
Ansonsten, ich habe noch einen Atmega644 im DIP-Gehäuse hier rumliegen, muss ich mir mal ein HM_LC_Sw1PBU_FM auf dem Steckbrett zusammenstecken.

Kannst du die Debugausgaben mal ausgeben lassen?

Gruß
Dirk

[DOCa Cola]

ah, danke für die erklärung.

Kannst du die Debugausgaben mal ausgeben lassen?

Naja, beim zusammenlöten hatte ich mir den UART port gespart... Ich hab den Schalter zZ in der Wand versenkt, habe mir aber einen ISP header herausgeführt den ich erreichen kann, wenn ich den Schalter ein Stück herausziehe (natürlich trotzdem mit ausgeschalteter Sicherung). Ist es möglich die relevanten Debug Meldungen via Homematic zu verschicken? Dann könnte ich sie via hmsniff auslesen.

[Dirk]

ah, danke für die erklärung.
Naja, beim zusammenlöten hatte ich mir den UART port gespart...

Stimmt TXD ist gar nicht nach Außen geführt.

Ist es möglich die relevanten Debug Meldungen via Homematic zu verschicken?

Theoretisch ja, ist aber etwas komplizierter, da der CC1101 ja mit Firmwaredaten beschäftigt ist. Da müsste man ständig umschalten.
Das LED-Geblinke ist ja schon ne kleine Debug-Ausgabe

Ich habe grade gesehen in der README.md von meinem Fork ist noch eine kleine "Unschärfe".
Welchen Befehl zum CRC-Berechnen hast du denn benutzt?
Der in meinem Repo ist für 32k-4k Flash-Speicher.

Bei dir sollte das so aussehen:

Code Auswählen Erweitern


srec_cat <payload.hex> -intel -fill 0xFF 0x0000 0xEFFE -Cyclic_Redundancy_Check_16_Little_Endian 0xEFFE -o payload.bin -binary

Ansonsten schreibt er den CRC an eine falsche Stelle.
Das könnte es auch noch sein.

Update:
Ich habe das im Github auch grade aktualisiert.

[DOCa Cola]

Ah, dann habe ich definitiv den falschen srecord Befehl angewandt. Hatte ich weiter oben ja auch schon gepostet (hast du vermutlich überlesen).
Ich werde heute Abend wieder testen können.

[unimatrix]

Laut Datasheet vom 644A (und sicher auch anderen Controllern):

Chapter 26.3.1: "...since the SPM instruction is disabled when executed from the application section"

So ganz einfach wirds also nicht gehen. "Einfach" ist es, wenn der Bootloader nur halb so groß ist wie der BL-Bereich. Dann passt er doppelt rein. Diesen Fall haben wir hier aber nicht vorliegen, im Gegenteil, es ist schon eng.

Nun ist ja der Teil des BL, der tatsächlich SPM ausführt, an sich sehr klein. Ein Großteil geht mit der Kommunikation über Funk drauf, usw. Folgendes Scenario ist eine Idee:

Annahme: Neben dem richtigen Bootloader passt noch ein Mini-Bootloader in den Bereich, ganz am oberen Ende. Dieser kann nix anderes, als zwischengespeicherten Code von irgendwo im Flash (müsste noch genügend NRWW-Flash da sein (noch zu prüfen) in den sicheren Teil des BLs zu schreiben (ausgenommen in den mini-bootloader-teil)

Wird per OTA ein Flashen des Bootloaders selbst initiiert (TBD: wie merkt das der BL) dann schreibt der BL die empfangenen Pages in den Beginn des NRWW Bereichs und springt dann als letzte Aktion in den Mini-Bootloader, der spielt dann seinerseits den zwischengespeicherten neuen BL vom Applikations-NRWW Bereich in den eigentlichen BL-Bereich.

Neben Details die zu klären sind, ergibt sich das Problem, dass , wenn man einen fehlerhaften BL so einspielt, man mit dem ISP ran muss. Ein CRC-Check geht, aber der sagt nix über Bugs aus. Der BL müsste vorher getestet worden sein.  Ebenfalls weiß ich nicht ob man den Build-Prozess so beeinflussen kann dass ein bestimmter Teil in einem bestimmten Speicher (am Ende) landet, der dann auch gezielt angesprungen werden kann.

[Dirk]

Annahme: Neben dem richtigen Bootloader passt noch ein Mini-Bootloader in den Bereich, ganz am oberen Ende. Dieser kann nix anderes, als zwischengespeicherten Code von irgendwo im Flash (müsste noch genügend NRWW-Flash da sein (noch zu prüfen) in den sicheren Teil des BLs zu schreiben

So könnte das gehen:

• Bootloader 1 startet
• Flash wird empfangen und in Programmsection geschrieben. Dieser Code beinhaltet quasi nur eine Sprungadresse zu Bootloader 2 und den Code vom Bootloader 1. Hier braucht man auch keine spezielle Upload-Mechanissmen. Das würde so jetzt schon funktionieren.
• Nach dem flashen und CRC-Prüfung wird das "Hauptprogramm" gestartet. Dieses enthält nur den Sprungbefehl in Bootloader 2
• Bootloader 2 startet und liest den Codeteil von BL 1 aus der Programmsection und Schreibt den an die Position von Bootloader 1
• Der code der Programmsection wird invalidiert so dass der Bootloader 1 nach einem Reset wieder startet
• Normaler Programmcode wird geflasht

Ich denke so könnte das gehen. Vermutlich braucht man dann wieder die 8k.
Man muss noch Schutzmechanismen einbauen, Dass der Bootloader sich nicht selber überschreiben kann.
Weil die Lockbits vom Bootloader können dann diesen Schutz nicht übernehmen.

Neben Details die zu klären sind, ergibt sich das Problem, dass , wenn man einen fehlerhaften BL so einspielt, man mit dem ISP ran muss. Ein CRC-Check geht, aber der sagt nix über Bugs aus.

Das ist klar.

Ebenfalls weiß ich nicht ob man den Build-Prozess so beeinflussen kann dass ein bestimmter Teil in einem bestimmten Speicher (am Ende) landet, der dann auch gezielt angesprungen werden kann.

Ja, das geht. So platziere ich auch in den letzten 16 Bytes die Adressdaten für das Device.

[unimatrix]

Sehr interessant. Man bräuchte für den kleinen Bootloader2 also nur die Funktion program_page() sowie eine kleine Funktion um eben genau die Aufgabe von BL2 zu machen (also kopieren aus dem unteren Flash in die BL-Sektion und Aufräumarbeiten.

Dies packt man in eine eigene .c Datei, kompiliert das, stellt mit avr-size die Größe fest, berechnet daraus die so groß wie mögliche Startadresse von BL2, und packt das dann in eine entsprechende Custom-Section per __attribute__.

Richtig gedacht?

[Dirk]

Ja, so ungefähr. Man muss dann noch die Pagegröße berücksichtigen. Da der Flash nur Pageweise beschrieben werden kann.
Klingt eigentlich ganz einfach

[DOCa Cola]

Mit dem richtigen srecord Befehl hat das einspielen der Firmware dann auch endlich geklappt Sehr schön!

Irgendwie durch wildes config button drücken habe ich es dann sogar geschafft das ganze mit FHEM zu pairen (lang drücken, kurz drücken??). Allerdings als unbekanntes Homematic device. Auf irgendeiner der Seiten dieses Threads hatte ich gelesen, dass man sich erst ein Dummy device anlegen soll, damit FHEM das perl file für den Switch läd... Das getan und nochmal alles zurückgesetzt und beim 2. mal hat er das ganze korrekt erkannt. Jetzt kann ich das Relais auch schön von FHEM aus schalten.
Schade, dass die eigentliche Firmware so schlecht dokumentiert ist. Echt schwierig sich die wichtigen Informationen aus den 40 Seiten hier zusammenzuklauben.

[Dirk]

Na super dass das geklappt hat.
Also können wir festhalten, dass der Bootloader auch mit dem HM_LC_Sw1PBU_FM funktioniert.
Danke für's testen.

@Jan soll ich dir mal einen Pullrequest schicken, oder magst du mir Zugriff auf dein Repo geben? Dann kann ich das ganze reinmergen.

Gruß
Dirk

[unimatrix]

Habe von Jan seit dem 7.8. nix gehört. Aber er hat ja schon geschrieben, dass es gemerged werden kann, insofern hat er wohl nix dagegen. Stell einfach einen Pull-Request. Wenn so wie heute neue Leute auf diese Firmware stoßen, kommen sie somit direkt auf die beste Version.

@DOCa Cola: was genau vermisst du denn an Doku? Das wesentliche ist eigentlich direkt in der README im Repository beschrieben. Dort findest du auch die FHEM - Datei, die du einspielen musst, damit der Custom-Firmware-Switch auch korrekt erkannt wird.

[DOCa Cola]

Ja, ich hatte die Datei auch im FHEM Verzeichnis. Trotz dessen wurde der Schalter als unknown model erkannt. Ich weis jetzt auch nicht ob es daran liegt.
Naja, ich hatte Probleme den Schalter mit FHEM zu pairen. Ich habe aufgrund dessen den Schalter mit hmsniff mal beobachtet. Mir ist unklar wie ich ihn dazu bringen kann, dass er sich paired. Irgendwie hat es dann doch geklappt.

Wie kann ich denn z.B einen physischen Schalter dazu bringen, dass er mir das Relais schaltet? Ich habe mich schon wieder durch etliche Seiten gelesen, aber konkret habe ich es nicht gefunden. Man muss den Schalter (Button) irgendwie mit dem switch pairen. Aber wie?

Irgendwie scheint es ja auch möglich sein den current auszulesen. Aber wo?
In der Readme steht: "Showing current sensor value in FHEM. (Copy device config below)."
Welche 'device config' ist damit denn gemeint (im text kommt nix mehr)? Die Datei hab ich schon in FHEM.
Ich habe 5 FHEM devices durch den Schalter. 1x das Gerät selbst, 2x button und 2x switches. In keinem habe ich eine current anzeige gesehen.

Ich muss allerdings auch sagen, dass der Schalter mein erstes HomeMatic device ist. So mag es sein, dass mir vielleicht ein bischen 'Allgemeinwissen' um diese fehlt.