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

Mr. P · 30 Juni 2014, 10:20:05

Zitat von: unimatrix am 30 Juni 2014, 09:57:32
Werde mir wohl einen Haufen eigene Debug-Ausgaben einbauen um den Code nach und nach zu verstehen...

Hej unimatrix,

finde ich toll, dass du dir die Zeit nimmst, um dich mit dem Code auseinander zu setzen.

mmattern · 30 Juni 2014, 10:24:16

Zitat von: mmattern am 25 Juni 2014, 09:17:52
- wenn man das Device jetzt einmal stromlos macht, geht es noch einmal in den Bootloader (erkennbar an Blinksequenz), dann aber nichts mehr: keine UART-Meldungen (weder vom Bootloader noch von der Firmware), der Schalter ist einfach nicht ansprechbar - Betätigen des Config-Buttons hat kein Blinken der LED oder Ausgabe der "i:0 s:0"-Meldung per UART mehr zur Folge...

Wenn die .hex-Version derselben Firmware per avrdude aufgespielt wird, funktioniert der Schalter...

Hallo zusammen,

das ist mir immer noch ein Rätsel... einen Schalter habe ich für Testzwecke mal beiseite gelegt - es ist wie verhext... das identische Firmware-File in der .hex-Version direkt aufgespielt funktioniert, in .eq3 gewandelt und per flash-ota aufgespielt wird nach dem Flashen gestartet und läuft, allerdings nur, bis das Device einmal stromlos gemacht wird. Danach signalisiert Blinken den Einsprung in den Bootloader, es passiert aber nichts Weiteres mehr, das Device schickt auch keine Funk-Messages...

Irgendeine Idee?

Vielen Dank & viele Grüße
Michael

Mr. P · 30 Juni 2014, 10:41:51

Zitat von: mmattern am 30 Juni 2014, 10:24:16
Irgendeine Idee?

Das selbe Problem hatte ich auch. Lag allerdings nicht am Firmware-File, sondern am Bootloader. Hatte ihn selbst gebaut (weil ich mir dachte, was soll bei einem make schon viel schief gehen) und vielen ungezählten Stunden bin ich dann dahinter gekommen, dass es am Bootloader und nicht an der Firmware liegt.
Ich hab dann den von Jan zur Verfügung gestellten verwendet (eben jenen, den ich auch übers Wiki verlinkt habe) und schon konnte ich die Firmware flashen und der Schalter behielt sie auch über stromlos machen hinaus.

unimatrix · 30 Juni 2014, 10:48:28

kann bestätigen dass ich das gleiche Bootloader-Problem hatte und dann den fertig gebauten genommen habe.

Ansonsten ist es wohl tatsächlich ver-HEX-t.

unimatrix · 30 Juni 2014, 17:57:47

nachdem ich nun mit dem Quellcode wesentlich klarer bin und nach dem Einbauen von zig Debug-Outputs ist mir der vorgang wesentlich klarer (hat mal jemand den UART Output so hinbekommen dass da auch CRs und nicht nur LFs gesendet werden??? - beim Bootloader klappts ja auch (andere lib) )

Es werden erst alle Peers abgearbeitet bevor dann tatsächlich geschaltet wird. Das sieht man sogar schon an der LED. Erst wird der Reihe nach der Button Press an alle Peers gesendet, dann blinkt die LED kurz, und erst dann wird der Switch geschaltet. Sobald ein Button keine peers außer den Switch intern hat, kann man ohne jegliche Verzögerung schnell ein und ausschalten. Sobald aber ein Peer da ist (virtueller Kanal, oder auch irgendein anderer HM Schalter), kommt es zu Latenzzeiten, Das Schalten des Lichts kann bis zu 3-4 Sekunden nach dem Tasterdruck erfolgen, was natürlich so nicht gut ist.

Problem besteht in der Lib selbst in dem es eben so ist dass die Peers abgearbeitet werden (logischerweise). Es war wohl beim erstellen der lib nicht vorgesehen (oder erschien zunächst nicht sinnvoll) dass man mit sich selbst als Device peert.

Obs dazu eine einfache Lösung gibt kann ich allerdings noch nicht sagen...zunächst bin ich dazu übergegangen bei meinen Tastern Btn_01 nur intern als Toggle zu peeren und den unteren Taster (BTN_02) für andere Aktionen, hierbei unterscheide ich dann Long und Short. Btn_01 Long kann ich somit nicht nutzen.

mmattern · 01 Juli 2014, 09:57:47

Zitat von: unimatrix am 22 Juni 2014, 19:28:12
Anhängend eine Firmware, von heutigem GIT, mit serieller Ausgabe.

Habs bei mir heute getestet und läuft.

Der Bootloader hat ja auch serielle Ausgabe (gerade ausprobiert)

Ich hatte am Anfang Probleme mit den Fuses....da liefs auch nicht. irgendwann gings dann. Wieso plötzlich, weiß ich nicht mehr.

Hallo unimatrix,

so, ich möchte jetzt nochmal gern probieren, das Ganze auch mit OTA-Flash ans Laufen zu bekommen...
Kannst du zu dieser Firmware noch das .eq3-File für flash-ota posten?

Vielen Dank & beste Grüße
Michael

Mr. P · 01 Juli 2014, 10:03:24

Hej Michael,

mit dem Bootloader aus der Freigabe funktioniert es:
https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5

mmattern · 01 Juli 2014, 14:23:04

Zitat von: Mr. P am 01 Juli 2014, 10:03:24
Hej Michael,

mit dem Bootloader aus der Freigabe funktioniert es:
https://owncloud.isengard.at/public.php?service=files&t=0df535e31ad6999664f0e84c95bd2ea5

Hallo Mr. P,

tatsächlich - mit dem funktioniert das Empfangen der Firmware... und auch nach Neustart des Devices (durch Stromabschaltung) erfolgt ein korrekter Start des Bootloaders und Sprung in die Firmware... (auch mit meiner selbst gebauten Firmware).
Also liegt es am Bootloader - selbst wenn ich frisch aus dem GIT-Repository unter https://github.com/jabdoa2/Asksin_OTA_Bootloader clone und dann baue, funktioniert es nicht, bzw. passiert genau das hier:
- Bootloader startet korrekt inkl. UART-Ausgabe
- Bootloader kann per flash-ota gesendetes File empfangen und flashen
- Empfangene Firmware startet und funktioniert inkl. UART-Ausgabe

ABER:
Nach Neustart des Devices blinkt zwar einmal die LED (vermutlich durch Bootloader-Start), danach funktioniert aber nichts mehr - und UART bleibt stumm.

Also die Frage: Wie kann ein funktionierender Bootloader gebaut werden? Ich habe es sowohl mit dem gcc-4.6.3 (Standard Raspbian Wheezy) als auch gcc-4.9 (mit avr-gcc 4.8.1) aus Raspbian Jessie probiert...
Selbst bauen würde ich gern, weil der Bootloader aus der Freigabe immer die Serial KEQ0123456 funkt... grundsätzlich natürlich gangbar, weil man ja immer nur ein Device zur Zeit flashen würde, aber es ist halt schön, wenn man weiß, dass es im Zweifel geht...

$:-\$ $:-\$ $:-\$

Vielen Dank & viele Grüße
Michael

mmattern · 01 Juli 2014, 14:25:10

Zitat von: unimatrix am 30 Juni 2014, 17:57:47
nachdem ich nun mit dem Quellcode wesentlich klarer bin und nach dem Einbauen von zig Debug-Outputs ist mir der vorgang wesentlich klarer (hat mal jemand den UART Output so hinbekommen dass da auch CRs und nicht nur LFs gesendet werden??? - beim Bootloader klappts ja auch (andere lib) )

Ich habe alle \n durch \r\n ersetzt und dann nochmal alle '\r\n' durch "\r\n"...
Dann geht's...

Viele Grüße
Michael

Mr. P · 01 Juli 2014, 14:43:52

Zitat von: mmattern am 01 Juli 2014, 14:23:04
tatsächlich - mit dem funktioniert das Empfangen der Firmware... und auch nach Neustart des Devices (durch Stromabschaltung) erfolgt ein korrekter Start des Bootloaders und Sprung in die Firmware... (auch mit meiner selbst gebauten Firmware).
Also liegt es am Bootloader - selbst wenn ich frisch aus dem GIT-Repository unter https://github.com/jabdoa2/Asksin_OTA_Bootloader clone und dann baue, funktioniert es nicht, bzw. passiert genau das hier:
- Bootloader startet korrekt inkl. UART-Ausgabe
- Bootloader kann per flash-ota gesendetes File empfangen und flashen
- Empfangene Firmware startet und funktioniert inkl. UART-Ausgabe

ABER:
Nach Neustart des Devices blinkt zwar einmal die LED (vermutlich durch Bootloader-Start), danach funktioniert aber nichts mehr - und UART bleibt stumm.

Also die Frage: Wie kann ein funktionierender Bootloader gebaut werden? Ich habe es sowohl mit dem gcc-4.6.3 (Standard Raspbian Wheezy) als auch gcc-4.9 (mit avr-gcc 4.8.1) aus Raspbian Jessie probiert...
Selbst bauen würde ich gern, weil der Bootloader aus der Freigabe immer die Serial KEQ0123456 funkt... grundsätzlich natürlich gangbar, weil man ja immer nur ein Device zur Zeit flashen würde, aber es ist halt schön, wenn man weiß, dass es im Zweifel geht...

$:-\$ $:-\$ $:-\$

Dann bist du jetzt genau an dem Punkt, bei dem ich damals auch war, nachdem ich einige Abende mit der Fehlersuche verbracht hatte und den Schalter endlich in der Wand versenken konnte.

unimatrix · 01 Juli 2014, 15:06:59

notfalls die Serien-Nummer im Hexfile patchen...bei mir läuft der selbst gebaute auch nicht.

mmattern · 01 Juli 2014, 16:20:57

Zitat von: unimatrix am 01 Juli 2014, 15:06:59
notfalls die Serien-Nummer im Hexfile patchen...bei mir läuft der selbst gebaute auch nicht.

auch ne Lösung... aber vielleicht liest ja auch der "Erzeuger" des funktionierenden Bootloaders mit und kann uns verraten, wie seine Toolchain aussieht...

Viele Grüße
Michael

P.S.:
Wer es ausprobieren möchte:

Im Original sehen Zeilen 251 und 252 wie folgt aus:
:10EF9400ABCDEF14000010ABCDEF000000004B45EB
:10EFA400513031323334353630313233343536370B

Die fett markierten Stellen enthalten die HMID (hier: ABCDEF) und dann die Serial (hier: KEQ0123456, HEX: 4B455130313233343536)

Wenn man das anpasst, meckert avrdude zunächst über eine falsche Prüfsumme (das sind immer die letzten beiden Zeichen einer Zeile, z.B. hier "EB" für Zeile 251).

Die Meldung sieht z.B. so aus:

Code Auswählen


avrdude: ERROR: checksum mismatch at line 251 of "bootloader_HM-LC-Sw1PBU-FM-2A32EB-KEQ0123460.hex"
avrdude: checksum=0xeb, computed checksum=0x2b

Man muss dann einfach in der angegebenen Zeile den bestehenden Wert (hier: EB) durch den in "computed checksum" ersetzen (hier also: 2B).

Dann geht es...

Mr. P · 01 Juli 2014, 17:15:13

Zitat von: mmattern am 01 Juli 2014, 16:20:57
auch ne Lösung... aber vielleicht liest ja auch der "Erzeuger" des funktionierenden Bootloaders mit und kann uns verraten, wie seine Toolchain aussieht...

Stimmt. Von Jan hab ich hier schon lange nichts mehr gelesen.
Wird doch hoffentlich nicht von irgendwas verschluckt worden sein.

mmattern · 01 Juli 2014, 19:09:31

Zitat von: jab am 07 April 2014, 20:44:32
Spannend. Das ist mehr oder weniger der gleiche Code. Welche GCC Version hast du denn? Ggf ist da irgendwas mit den Timings nicht perfekt in der Klasse. Das Problem hatten leider schon ein paar andere. Ich hänge mal meine hex vom Bootloader an. Vielleicht geht die bei dir.

Gruß,
Jan

Hallo Jan,

deine Version funktioniert prima... wie hast du die denn kompiliert (z.B. welche Version avr-gcc)? Eine Reihe von Forumsmitgliedern hier haben sich am Selbstbau versucht und haben jeweils merkwürdige nicht funktionierende Versionen erzeugt... sie funktionieren für den ersten Start, empfangen die Firmware und sobald das Device dann einmal stromlos wird, war es das dann...

Viele Grüße
Michael

jab · 02 Juli 2014, 23:40:20

Moin,

ich bin im Augenblick viel Unterwegs. Eigentlich wollte ich noch mal irgendwann ein Usertreffen veranstalten. Im Raum Hannover ggf wenn Interesse besteht. Alternativ Ende des Jahres in Hamburg beim CCCC Congress.

Zu dem Buildproblemen: Ursprünglich ging es nur mit GCC 4.6. Die Probleme habe ich aber eigentlich gefixt. Aktuell nutze ich GCC auf Ubuntu 13.10 (4.8.1) und Ubuntu 14.04 (weiß gerade nicht genau). Im Bootloader sollte das eigentlich alles gehen. Muss ich mir sonst noch mal angucken.

Was für aktuelle Probleme gibt es denn? Können wir eine Liste machen? Gerne auch als Issues auf github dann kann man die besser tracken.

Gruß,
Jan