Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[betateilchen]

Code Auswählen Erweitern


perl flash.pl Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex F1:02 B4:88:98 UWS2370787

Test  Bootloader connection

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


Write Bootloader

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin"
avrdude: writing flash (4096 bytes):

Writing | ################################################## | 100% 3.13s

avrdude: 4096 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.bin contains 4096 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.08s

avrdude: verifying ...
avrdude: 4096 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.



Code Auswählen Erweitern


./flash-ota  -f HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 -s UWS2370787
HomeMatic OTA flasher version 0.097-git

Reading firmware from HB-UW-Sen-THPL_update_V0_14_001_150301.eq3...
Firmware with 224 blocks successfully read.

Rebooting HM-CFG-USB to avoid running out of credits

HM-CFG-USB not in bootloader mode, entering bootloader.
Interrupt transfer not completed: Unknown error code 5 / 0x05!
Can't send null frame: No such device (it may have been disconnected)
Waiting for device to reappear...
Can't release interface: No such device (it may have been disconnected)
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!
HM-CFG-USB in bootloader mode, rebooting
Can't find/open hmcfgusb!
Can't find/open hmcfgusb!


HM-CFG-USB opened

HM-CFG-USB firmware version: 967
Entering 10k-mode
Waiting for device with serial UWS2370787


Wie krieg ich denn den Sensor in den Update-Mode? Irgendwie gibt der überhaupt kein Lebenszeichen mehr von sich...

[vbs]

Nach dem Power-On muss die LED 7-mal blinken (wegen V0.7), ansonsten läuft der Bootloader nicht korrekt. Du kannst dich auch mal per seriell verbinden. Beim Starten macht er auch Ausgaben in der Art "Asksin Bootloader 0.7" und dann zyklisch "Sending blabla". Falls das alles nicht kommt, dann ging irgendwas schief.

[betateilchen]

es blinkt überhaupt nichts mehr...

[frank]

Wie krieg ich denn den Sensor in den Update-Mode?

batterie raus, taster drücken, batterie rein und wenn der download anfängt (flackernde led), taster loslassen.

Irgendwie gibt der überhaupt kein Lebenszeichen mehr von sich...

sniffe einmal den sensor mit attr logIDs des hmusb.

[betateilchen]

es blinkt nichtmal mehr beim Einlegen der Batterien...

[vbs]

Ich hatte nach dem Flashen des Bootloaders das gleiche Problem: Gerät danach tot.

Bei mir lag es irgendwie daran, dass die hex2bin-Umwandlung nicht korrekt war. Wenn ich das Hex-File (ohne gepatchte Seriennummer/HMID) direkt geflasht habe, dann lief der Bootloader. Wenn ich jedoch das Skript benutzt habe, welches ja zunächst das Hex-File nach Bin wandelt, dann war der Sensor danach tot. Ich hab mir dann so beholfen: http://forum.fhem.de/index.php/topic,20620.msg269962.html#msg269962

Mag bei dir natürlich auch ganz was anderes sein... Aber probier doch einfach mal den unbehandelten Hex-Bootloader zu flashen. Ob er denn dann erstmal ein Lebenszeichen von sich gibt.

[betateilchen]

Code Auswählen Erweitern


~/AskSinBootloader_Flash-Tool-RaspberryPi# bin/avrdude -Cbin/avrdude.conf -p atmega328p -P gpio -c gpio -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:r -Ulock:w:0x2F:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude: writing flash (10744 bytes):

Writing | ################################################## | 100% 5.89s

avrdude: 10744 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex contains 10744 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.09s

avrdude: verifying ...
avrdude: 10744 bytes of flash verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.


Der einzige erkennbare Unterschied ist für mich, dass dabei 10744 Bytes geschrieben werden anstatt 4096 wie vorher.

Am Verhalten des Sensors ändert sich aber nichts


Edit: ich hab es nun auch mit "i" anstatt "r" als Format probiert, dann werden 32k geschrieben, was aber auch nix ändert.

[vbs]

Die einzige Idee, die ich noch hätte, wäre, zu gucken, ob die Fuse-Bits richtig gesetzt sind. Ich hatte zum Beispiel mal händisch die Fuse-Bits, die die Größe des Bootbereichs angeben, von 2k auf 4k ändern müssen. Davor ging gar nix. Aber soviel ich weiß, macht das alles das Flash-Skript schon für dich. Ich meinen ersten Versuch mit AVRStudio gemacht und da musste ich eben alles händisch machen.

Hier ein Post von Dirk, wo drinsteht, wie die Fuses gesetzt sein müssen:
http://forum.fhem.de/index.php/topic,20620.msg269627.html#msg269627

[betateilchen]

Die einzige Idee, die ich noch hätte, wäre, zu gucken, ob die Fuse-Bits richtig gesetzt sind.

von sowas hab ich keine Ahnung

[betateilchen]

so... den zweiten Sensor habe ich auf die gleiche Art und Weise jetzt auch umgebracht *grummel*

[frank]

von sowas hab ich keine Ahnung

ist auch nicht nötig. genauso wie beim flashen, nur einen anderen befehl. als bsp aus dem git vom bootloader:

Code Auswählen Erweitern

avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m

[betateilchen]

Du bist mein Held, ich sehe rote Lichtzeichen. Jetzt muss ich die nur noch "interpretieren"...

[frank]

Jetzt muss ich die nur noch "interpretieren"

einfach sniffen.

[betateilchen]

da kommt nix zum sniffen...

Ich fasse mal zusammen:

Wenn ich das HEX File (ohne Id und Seriennummer) zusammen mit den fuse bits flashe, bekomme ich hinterher 7 mal rotes Blinken.
Aber in fhem bekomme ich mit logIDs all,sys keine verwertbaren Infos, ausserdem hätte ich ja gerne die gleiche HMId und S/N wie vorher auch.

Also muss ich irgendwie den von vbs beschriebenen Weg gehen, um ein brauchbares BIN file zu bekommen.

http://forum.fhem.de/index.php/topic,20620.msg269962.html#msg269962

Kann mir jemand den aufgeführten Schritt 2 (Auslesen des geschriebenen HEX files aus dem Sensor) erklären?

[betateilchen]

da kommt nix zum sniffen...

doch, da kommt was:

Code Auswählen Erweitern


2015-03-14 17:35:53.893600: 14000010ABCDEF0000000048423044656661756C74
Packet information:
Length: 20
Message ID: 0
Sender: abcdef
Receiver: 000000
Control Byte: 0x00
Flags:
Message type: Information (0x10)
Mesage: 0048423044656661756C74