Alternative culfw

stefanru · 27 November 2016, 18:26:32

Hm,

868er geht auch nicht aber ohne das blinken danach:

Call now avrdude -p atmega328p -c arduino -P /dev/ttyUSB1 -b 57600 -D -Uflash:w:./nanoCUL868.hex:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: reading input file "./nanoCUL868.hex"
avrdude: writing flash (31002 bytes):

Writing | ################################################## | 100% 8.34s

avrdude: 31002 bytes of flash written
avrdude: verifying flash memory against ./nanoCUL868.hex:
avrdude: load data flash data from input file ./nanoCUL868.hex:
avrdude: input file ./nanoCUL868.hex contains 31002 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.24s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7800
         0x0c != 0x30
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

Würdest du dann einen anderen arduino empfehlen?
Will den ja schon benutzen und auch mit neuester firmware versehen können.

Am besten kauf ich wohl einen mini?

Gruß,
Stefan

bjoernh · 27 November 2016, 18:51:01

Ne, muss eigentlich gehen. Ich probiere es später mal.

Burny4600 · 27 November 2016, 19:34:01

Völlig egal um welchen nanoCUL es sich handelt von 7 nanoCULs mit der aktuellen Version 1.23.00 funktioniert nur einer und das ist ein 868 mit einem FTDI Chipsatz.
Das war aber auch wahrscheinlich nur ein Zufall.
Das Flashen lief bei allen nanoCUL problemlos ab. Keiner meldete beim Flashen irgendeinen Fehler.
Nach dem Neustart verhalten sich Stück unterschiedlich. Die einen blinken, die anderen leuchten.
Unter FHEM melden aber alle opened.

Das Problem ist aber das die nanoCULs mit ls -al /dev/serial/by-id alle noch angezeigt werden, aber keiner dieser Stück, ob FTDI Chipsatz oder nicht, lassen sich neuerlich Flashen was das gravierender Problem ist.

Der eine 868er lässt sich trotz aktueller V1.23 neuerlich flashen.
Das Verhalten ist als ob FHEM oder ser2net noch laufen würde was aber nicht der Fall ist.

Code Auswählen

7:/media/hdd/nanoCUL $ bash flash.sh
-------------------------------------------------------------
This program flash the cul device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please choose a device:
 1 = nanoCUL868
 2 = nanoCUL433
Please select device (1-2): 1
-------------------------------------------------------------
This program flash the cul device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please insert the port for your device [default /dev/ttyUSB0]: /dev/ttyUSB1

The device will now be flashed
Continue (y/n)?y
Call now avrdude -p atmega328p -c arduino -P /dev/ttyUSB1 -b 57600 -D -Uflash:w:./nanoCUL868.hex:i
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

Das ist jetzt sch..... da ich des Update durchgeführt hatte ohne einen Blick in das Forum zu machen.

bjoernh · 27 November 2016, 20:24:49

Es ist zu 100% ein speicher Problem, wenn einige Funktionalitäten raus fliegen, dann geht es wieder. Ich werde eine Version einchecken wo es der nanoCUL wieder geht.

Burny4600 · 27 November 2016, 20:27:20

Sollte es nicht möglich sein eine ältere Version die schon funktionierte wieder darauf zu packen?

Ich hätte versucht die V1.21 wieder zu flashen, aber ohne Erfolg.

bjoernh · 27 November 2016, 20:32:50

Zitat von: Burny4600 am 27 November 2016, 20:27:20
Sollte es nicht möglich sein eine ältere Version die schon funktionierte wieder darauf zu packen?

Ich hätte versucht die V1.21 wieder zu flashen, aber ohne Erfolg.

Das Problem ist, dass der Code zu groß ist. avrdude schreibt den in den Arduino ohne den Bootloader zu berücksichtigen. Dann wird der Bootloader überschrieben.
Du bekommst die nanos dann leider nur noch via ISP wieder zum laufen. Sprich Du musst zuerst den Boolloader reparieren. Einen anderen Weg gibt es leider nicht.

So, der Build ist durch 1.23.01

stefanru · 27 November 2016, 21:26:04

Du hast doch sicher noch nen arduino. Mit dem kannst du den anderen per ISP wieder beleben.
Hab ich auch so gemacht.
Siehe hier:
https://forum.fhem.de/index.php/topic,35064.msg529637.html#msg529637

@bjoern:
Komisch bei mir hat das rauswerfen von Funktionalität nicht geklappt gehabt.
Aber wenn du ne neue Version hast teste ich sie gerne.
Hab jetzt nen extra nano zum wiedrbeleben der anderen. Dauert keine 2 min

Gruß,
Stefan

bjoernh · 27 November 2016, 21:49:09

Zitat von: stefanru am 27 November 2016, 21:26:04
Du hast doch sicher noch nen arduino. Mit dem kannst du den anderen per ISP wieder beleben.
Hab ich auch so gemacht.
Siehe hier:
https://forum.fhem.de/index.php/topic,35064.msg529637.html#msg529637

@bjoern:
Komisch bei mir hat das rauswerfen von Funktionalität nicht geklappt gehabt.
Aber wenn du ne neue Version hast teste ich sie gerne.
Hab jetzt nen extra nano zum wiedrbeleben der anderen. Dauert keine 2 min

Gruß,
Stefan

Na dann leg los

stefanru · 27 November 2016, 22:19:09

Alles super! Danke!!!

Was war es denn jetzt, bzw. was hast du geändert?

Code Auswählen

Call now avrdude -p atmega328p -c arduino -P /dev/ttyUSB1 -b 57600 -D -Uflash:w:./nanoCUL433.hex:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: reading input file "./nanoCUL433.hex"
avrdude: writing flash (30708 bytes):

Writing | ################################################## | 100% 8.28s

avrdude: 30708 bytes of flash written
avrdude: verifying flash memory against ./nanoCUL433.hex:
avrdude: load data flash data from input file ./nanoCUL433.hex:
avrdude: input file ./nanoCUL433.hex contains 30708 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.19s

avrdude: verifying ...
avrdude: 30708 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

mahowi · 28 November 2016, 18:26:14

Ich habe jetzt die neue Version kompiliert und aufgespielt. avrdude meldet auch keine Fehler beim verifying (Ausgabe wie bei stefanru). Aber jetzt wird der nanoCUL von fhem nicht mehr gefunden:

Code Auswählen

2016.11.28 18:21:17.747 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.11.28 18:21:17.856 5: SW: V
2016.11.28 18:21:20.870 5: SW: V
2016.11.28 18:21:23.884 5: SW: V
2016.11.28 18:21:26.900 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600KGR0-if00-port0, ignoring it (nanoCUL)

Bootscreen · 28 November 2016, 18:27:51

Hallo bjoernh,

da ich inzwischen wieder mal ein wenig Luft habe, wollte ich nochmal da ansetzen wo ich letztes Jahr schonmal nachgefragt hatte, wie kann man dir helfen zusätliche Protokolle zu implementieren? Speziell geht es mir um das Techlico Protokoll. Pilight hat das Protocol schon "entschlüsselt" / eingebaut: https://wiki.pilight.org/doku.php/techlico
Das ist bei mir nämlich der einzige Grund warum noch pilight läuft und ich würde das gerne ganz abschalten.

Burny4600 · 28 November 2016, 18:35:57

Zitat von: stefanru am 27 November 2016, 21:26:04
Du hast doch sicher noch nen arduino. Mit dem kannst du den anderen per ISP wieder beleben.
Hab ich auch so gemacht.
Siehe hier:
https://forum.fhem.de/index.php/topic,35064.msg529637.html#msg529637

Leider hat sich kein einziger wieder beleben lassen.
Ich bekomme nach einer gewissen Zeit wenn der Bootloader neu geschrieben wird ähnlich Fehlermeldungen wie beim Flashen.
Verwendet habe ich die aktuellste Software (arduino-1.6.13-windows.exe).
Mit welcher Arduino Version hat das bei Euch funktioniert?

stefanru · 28 November 2016, 19:13:51

Hi Burni,
hatte ich auch genau so. Ohne vom USB abziehen gleich nochmal Bootloader flaschen. Dann kam zwar eine Warnung und die Sticks blinkten immer noch, aber in der Fusszeile stand Bootloader erfolgreich geflashed. Danach abgezogen und es war alles wieder ok.

Gruss,
Stefan

bjoernh · 28 November 2016, 19:52:06

Zitat von: Bootscreen am 28 November 2016, 18:27:51
Hallo bjoernh,

da ich inzwischen wieder mal ein wenig Luft habe, wollte ich nochmal da ansetzen wo ich letztes Jahr schonmal nachgefragt hatte, wie kann man dir helfen zusätliche Protokolle zu implementieren? Speziell geht es mir um das Techlico Protokoll. Pilight hat das Protocol schon "entschlüsselt" / eingebaut: https://wiki.pilight.org/doku.php/techlico
Das ist bei mir nämlich der einzige Grund warum noch pilight läuft und ich würde das gerne ganz abschalten.

Hallo,

zuerst sollten wir wissen, ob der CUL bereits etwas empfängt.
Schalte dazu mal RAW X25 ein und schneide mit einem Terminal mit.
Wenn da etwas kommt, muss man evtl. die Firmware erweitern.

Weißt Du ob es für Fhem ein Modul gibt? Wenn ja, müsste man dieses dann vom CUL aus adaptieren, hierzu hatte ich das CUL_REDIRECT Modul eingeführt.

Burny4600 · 28 November 2016, 20:01:34

Zitat von: stefanru am 28 November 2016, 19:13:51
Hi Burni,
hatte ich auch genau so. Ohne vom USB abziehen gleich nochmal Bootloader flaschen. Dann kam zwar eine Warnung und die Sticks blinkten immer noch, aber in der Fusszeile stand Bootloader erfolgreich geflashed. Danach abgezogen und es war alles wieder ok.

Hallo Stefan!

Werde mir morgen etwas mehr Zeit nehmen, um dem Verhalten des Bootloader Aufspielens auf dem Grund zu gehen.