AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

Xent

Die Fuses waren Ok.
Ich habs jetzt auch irgendwie hinbekommen.

Ich hatte das ganze einmal mit und einmal ohne Funkmodul probiert.
Am Anfang muss ich wohl irgendwas falsch gemacht haben, daher bin ich davon ausgegangen, dass man den Atmega nicht flashen kann, wenn das Funkmodul angeschlossen ist.
Dann hab ichs halt auf nem blanken Pro Mini probiert aber hier scheint ohne Funkmodul überhaupt keine Ausgabe zu kommen.
Habs dann in verschiedenen Konstellationen immer wieder probiert aber scheinbar immer wenn ich es beim Arduino mit Funkmodul probiert habe immer nen teil vom Programmer angeschlossen gelassen.
Das hat so wie es aussieht das booten verhindert.

Also kurz zusammen gefasst:
1. bei der makeota.html direkt die Firmware des Sketches angeben
2. Flashen mit Funkmodul funktioniert
3. Programmer komplett trennen
4. mehrere Sekunden auf die erste Ausgabe warten

Der Sketch wird nun auch direkt gestartet.

Ich werd trotzdem gleich mal das OTA Flashen testen, einmal über die CCU und einmal über das Tool.
Muss man dort die Firmwareversion oderso anpassen damit man es neu flashen kann über die CCU?
Also damit die CCU erkennt, dass es eine neue Firmware ist.

jp112sdl

Ich hatte dein File mal testweise geflasht.
Da kam auch nix... bis ich dann gesehen hab, dass die Boot Size Fuse nicht korrekt war.
Anschließend ging es auf Anhieb.

Was die CCU betrifft, siehe hier ganz unten:
https://github.com/pa-pa/AskSinPP/tree/master/bootloader/avr
In der info Datei muss die FirmwareVersion größer sein, als die, mit der das Gerät angelernt wurde.
Und sie sollte oder muss der Version entsprechen, die du im Sketch kompiliert hast, sonst wird dir das Update immer wieder angeboten... (z.B. Sketch = 1.0; info = 1.1)
Andererseits musst du bei der Versionierung der Firmware auch schauen, ob die Geräte-XML in der CCU nicht fix versionsgebunden ist!
z.B. rf_bl_le_v2_3.xml

<device version="1" supports_aes="true">
<supported_types>
<type name="radio-controlled blind actuator 1-channel (surface-mount)" id="HM-LC-Bl1-SM" priority="2">
<parameter index="9.0" size="1.0" cond_op="LE" const_value="0x23"/>
<parameter index="10.0" size="2.0" const_value="0x0006"/>
</type>
...

Die geht nur für Firmware Version <= 2.3

Je nach Firmwareversion kann es (bzw. wird es) unterschiedliche Geräte-Parameter geben.

Xent

#1322
Habs jetzt mal an die CCU angelernt und dann mit dem Tool in den Bootloader geschickt.

Irgendwie scheint die Datei defekt zu sein.
Habs mit Cygwin unter Windows und der prepareforota.sh umgewandelt.
Ich wandel die Firmware jetzt nochmal mit prepota.sh unter Linux um. Dauert aber etwas ...

HomeMatic OTA flasher version 0.103-git

Reading firmware from HB-UNI-RGB-LED-CTRL.ino_201910051323.eq3...
Firmware with 224 blocks successfully read.
HM-MOD-UART firmware version: 1.4.1, used credits: 4%

HM-MOD-UART opened

Entering 10k-mode
Adding HMID
Sending device with hmid 353dbb to bootloader
Waiting for device with serial USV3261990
Device with serial USV3261990 (HMID: 353dbb) entered firmware-update-mode
Adding HMID
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0056/0224 /
Missing ACK!
Flashing 224 blocks: 0135/0224 /
Missing ACK!
Flashing 224 blocks: 0218/0224 /
Missing ACK!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot
Device rebooted


AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Got CB msg
Switch to 100k mode
Receive firmware
Got CB msg
.......................................................pageSize and blockPos differ
...............................................................................blockLen differ pageSize
blockLen differ pageSize
blockLen differ pageSize
....................................................................................Retransmit, reflash!<\n>
.......Timeout
CRC OK
Start App
AskSin++ V4.0.2 (Oct  4 2019 21:29:13)<\n>
Address Space: 32 - 844
CC init1
CC Version: 14


EDIT: gleiches Problem mit der unter Linux erstellen eq3 Version

jp112sdl

Kann auch passieren, wenn anderen Geräte dazwischenfunken.
Nach einer gewissen Anzahl retransmits ist schluss.
Hat mich alles nicht so überzeugt. Hab dann auch aufgehört, mich weiter mit OTA zu befassen

Xent

Obwohl, wenn ich mir es genau anschaue, dann sagt er ja am Ende CRC Ok.
Sollte also funktioniert haben ...

Ich muss nacher mal was am Sketch ändern, damit ich sehe dass die neue Version angekommen ist.

Ich hoffe mal das Funktioniert alles ...
Wenn ich meine Gartenleuchten wieder zusammengebaut habe, kommt man da nicht mehr so einfach dran, daher das OTA und Reset durch An/Aus Sequenz.

Xent

Flashen OTA funktioniert ohne Probleme.

Allerdings habe ich gerade nen komisches Problem.
Es funktionierte alles, nur wollte ich was bauen, damit ich die Reset-Blink-Anzeige nicht auf der Status LED habe, sondern auf der RGB LED.
Damit ich nicht alles umbauen muss im Code war der Plan auf den Pin 3 einen Interrupt zu legen und diesen mit Pin 4 der eigentlichen Status LED zu verbinden.
Im Interrupt wollte ich dann prüfen ob der Sketch gerade gestartet wurde und noch innerhalb der Resetzeit ist.
Falls ja, soll bei jedem triggern die RGB LED an/aus geschaltet werden.

Habe das ganze dann wieder OTA geflasht.
Aber nun scheint nichts mehr vom Gerät empfangen zu werden. Ich sehe wie was gesendet wird, aber es kommt kein ACK.
Habe darauf hin wieder die alte Firmware OTA geflasht. Dies hat auch funktioniert, also ist der CC1101 immernoch richtig verbunden.
Gebracht hat es aber nichts ...

Habs jetzt auch nochmal normal geflasht, hat aber auch nichts gebracht.


Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?

jp112sdl

Zitat von: Xent am 06 Oktober 2019, 17:36:45
Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?
Ja. https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#ermittlung-der-cc1101-frequenz

Xent

Werd den Sketch mal drüber laufen lassen ...
Beim ersten mal hat das Anlernen sofort funktioniert und auch die Bedienung funktionierte ohne Probleme.

Könnte es sein, dass es mit dem ResetOnBoot zutun haben könnte.
Erst danach trat das Problem auf.

Als eingestellte Frequenz wird mit folgende ausgegeben:
Config Freq: 0x21FFFF

Vielleicht hat sich da ja was Adressenmäßig verschoben.
Hab leider gerade keine Ausgabe von nem anderen Arduino da zum Vergleichen.

jp112sdl

Zitat von: Xent am 06 Oktober 2019, 18:03:20
Könnte es sein, dass es mit dem ResetOnBoot zutun haben könnte.
Erst danach trat das Problem auf.

Als eingestellte Frequenz wird mit folgende ausgegeben:
Config Freq: 0x21FFFF

Vielleicht hat sich da ja was Adressenmäßig verschoben.
Eigentlich nicht.
Die bei den Freq-Bytes werden in Config Byte 0 und 1 abgelegt.
Der Bootstate für den Reset in Byte 2
https://github.com/pa-pa/AskSinPP/blob/7efdd76da8ec6bfe734b5d42416b0d407a87a7cf/AskSinPP.h#L14

Wenn die ResetOnBoot-Routine das Gerät zurücksetzt, wird die selbe Methode aufgerufen, wie beim Lange-Config-Taster-Gedrückthalten.
https://github.com/pa-pa/AskSinPP/blob/8e235f54c6a31c9485be6e60632d58274ff199ba/ResetOnBoot.h#L61
Die Freq bleibt dabei eigentlich erhalten.

Getestet habe ich es jedoch nicht.

jp112sdl

Habs mal fix durchgespielt.
Freq blieb auch nach ResetOnBoot erhalten.

papa

Zitat von: Xent am 06 Oktober 2019, 17:36:45
Habs jetzt auch nochmal normal geflasht, hat aber auch nichts gebracht.

Gabs schonmal sonen Problem wo zwar die Initialisierung des Funkmoduls funktioniert usw. aber nichts empfangen wird?
Da ja der alte Code geht, hast Du bestimmt irgendwas bei den Interrupts verdreht und nun kriegt das Funkmodul nicht mehr mit, dass eine Nachricht reingekommen ist.
Ich habe mal eben schnell die ResetOnBoot-Klasse etwas geändert und eine virtuelle led() Methode eingeführt. Diese ist jetzt für die Signalisierung zuständig. Du kannst jetzt einfach eine neue Klasse ableiten und deine eigene On/Off Methode implementieren.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Also irgendwas muss da schiefgegangen sein bei der Freuqenz ...

Fand es ja schon komisch, dass es gerade 21FFFF war.
Nachdem ich den FrequenzSketch hab laufen lassen kam folgende Freuenz raus:
Config Freq: 0x21654A

Jetzt hab ich wieder den Sketch drauf der nicht lief und diesmal funktioniert alles.

Danke papa.
Werd ich mir morgen mal anschauen.

Tom Major

Zitat von: Xent am 06 Oktober 2019, 20:25:37
Also irgendwas muss da schiefgegangen sein bei der Freuqenz ...

Fand es ja schon komisch, dass es gerade 21FFFF war.
Nachdem ich den FrequenzSketch hab laufen lassen kam folgende Freuenz raus:
Config Freq: 0x21654A

FF ist der Inhalt einer gelöschten bzw. noch nie benutzten EEPROM Zelle. Die 21 wird nicht mit gespeichert wenn ich mich richtig erinnere.
Sieht für mich so aus das mit 21FFFF der FrequenzSketch noch nie gelaufen ist oder die Frequenz irgendwie danach wieder aus dem EEPROM gelöscht wurde.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Xent

Den Sketch hatte ich bisher noch nicht laufen lassen auf dem Arduino.

Also ich vermute ja, dass das irgendwie gelöscht wurde.
Hatte ja auch die vorherige Version des Firmware geflasht und es funktionierte immer noch nicht.
Zuerst lief ja alles.

Vielleicht sollte man noch ne Prüfung einbauen, ob der Wert plausibel ist und bei FFFF oder 0000 dann den Standard nimmt.
Wenn man noch etwas Platz im EEPROM hat könnte man ja auch noch ne Checksumme  drauf legen.

Vielleicht hing das ja auch mit dem OTA Flashen zusammen.

Ich werd bei meinen Lampen jedenfalls den Pin 8 nach GND brücken und im Sketch einen anderen Config-Pin definieren.
So kann ich zumindest immer OTA flashen wenn ich das Teil einschalte.

jp112sdl

Zitat von: Xent am 07 Oktober 2019, 10:52:33
Vielleicht sollte man noch ne Prüfung einbauen, ob der Wert plausibel ist und bei FFFF oder 0000 dann den Standard nimmt.
Wenn man noch etwas Platz im EEPROM hat könnte man ja auch noch ne Checksumme  drauf legen.
Wird doch alles gemacht.
https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
https://github.com/pa-pa/AskSinPP/blob/30b03a0bdc2f84dd5a1ca4ced4090c51011810df/AskSinPP.h#L175

Man müsste halt rausfinden, warum die StorageConfig valid war, bzw. wenn der Rest gestimmt hat, warum nur die FreqConfig-Bytes FF waren.