CUL Selbstbau nach dem flashen

Begonnen von littleswabi, 02 März 2016, 13:49:49

Vorheriges Thema - Nächstes Thema

littleswabi

Hallo Leute :)

mittlerweile verzweifle ich bald mit dem CUL im Selbstbau. Nachdem ich mich an die Anleitung im WIKI gehalten habe  hatte ich auch anfänglich den CUL Stick im Fhem initialisiert bekommen. Er hat auch Daten empfangen und gesendet allerdings meine Steckdosen haben nicht geschaltet.

Was mich etwas verwundert hat, denn wenn ich an der FB an bzw. aus geschaltet habe hat sich der Status in Fhem dementsprechend geändert und ich konnte auf dem Atmega auch sehen, dass die RX und TX LED blinkten.

Nun liest man ja immer soooo viel unterschiedliche Sachen und ich bin dann auf die "alternative culfw" http://forum.fhem.de/index.php/topic,35064.0.html gestoßen.

Gesagt getan und auf den PI gezogen ins Verzeichnis gewechselt und bei flashen ist dann wohl etwas falsch gelaufen  :(


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

avrdude: AVR device initialized and ready to accept instructions

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

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

Writing | ################################################## | 100% 10.08s

avrdude: 30976 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 30976 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.87s

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

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

avrdude done.  Thank you.


Nun blinkt auf dem Controler die LED neben Power (ich glaube da steht ein L) recht schnell und ein erneutes flashen ist nicht mehr möglich.

Wie kann ich das wieder rückgängig machn?!

Danke und Gruß

Michael

littleswabi

#1
Hat keiner von euch eine Idee? 



Spezialtrick

#2
Das schnelle Blinken der LED habe ich auch immer nach dem Flashen. Zieh den NanoCul einfach einmal ab und schließ ihn wieder an.

Dann verschwindet das Blinken und er wird erkannt.

Allerdings scheint beim Flashen auch etwas schief gegangen sein. Avrdude hat ja einen Fehler beim kontrollieren der geschriebenen Daten gemeldet.
FHEM - Debmatic - Zigbee2MQTT - Homekit

RaspiLED

Hi, wie ist den die Fehlermeldung beim Versuch neu zu flashen? Hast Du den Arduino mal ganz vom Strom / USB getrennt? Hat er noch ein ttyUSB0 oder evtl. eine andere Adresse? Was sagt ls -la /dev/serial/by-id/* ? Gibt er noch per minicom Lebenszeichen von sich? Evtl. mit anderer Baudrate flashen möglich (-b 9600)?

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Feuerdrache

Moin,
taucht der Arduino denn noch in der Liste der USB Geräte (lsusb) auf?

Gruß FD
FHEM auf Raspberry PI B2
- CUL V3.4 mit culfw 1.65 für HM
- nanoCUL mit culfw 1.66 für KOPP FreeControl

littleswabi

Guten Morgen,

erstmal danke für die Anworten....

ZitatSpezialtrick
Das schnelle Blinken der LED habe ich auch immer nach dem Flashen. Zieh den NanoCul einfach einmal ab und schließ ihn wieder an.

Dann verschwindet das Blinken und er wird erkannt.

das habe ich auch schon probiert aber das schnelle Blinken der LED auf dem Controler bleibt.

ZitatArndBaumgarten
Hi, wie ist den die Fehlermeldung beim Versuch neu zu flashen? Hast Du den Arduino mal ganz vom Strom / USB getrennt? Hat er noch ein ttyUSB0 oder evtl. eine andere Adresse? Was sagt ls -la /dev/serial/by-id/* ? Gibt er noch per minicom Lebenszeichen von sich? Evtl. mit anderer Baudrate flashen möglich (-b 9600)?

ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Mär  3 09:01 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0


der Controler wird also noch erkannt aber wenn ich nochmals flashen will kommt folgendes. Ich habe die Geschwindigkeit auf 9600 gestellt.


#@if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
#@if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
#echo out > /sys/class/gpio/gpio17/direction
#echo out > /sys/class/gpio/gpio18/direction
#echo 0 > /sys/class/gpio/gpio17/value
#echo 0 > /sys/class/gpio/gpio18/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio17/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio18/value
avrdude -D -p atmega328p -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -b 9600 -c arduino    -U flash:w:nanoCUL.hex
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
^Cmakefile:216: recipe for target 'program' failed
make: *** [program] Unterbrechung


Ich habe gestern Abend mal noch ein wenig gelesen habe er nicht wirklich was gefunden. Der Bootloader scheint wohl noch in ordnung zu sein.

http://www.instructables.com/id/A-solution-to-avrdude-stk500getsync-not-in-syn/

ZitatUnlikely Cause #1: Bootloader is missing

Before we begin, we should check the bootloader of the Arduino for comprehension. If the bootloader is gone or corrupt, this can cause the issue.

To do this: power and reset the board. Check to see if the pin 13 built-in LED lights; if it is not then your bootloader may be missing. If this is the case, then your problem is beyond the scope of this guide. I would suggest visiting this Sparkfun guide: http://www.sparkfun.com/tutorials/247.

Wenn ich die herkömmliche Software 1.66 flashe hat das auch immer gut geklappt. Nur diese modifizierte CUL_V3.hex erzeugt diesen Fehler.

RDK

Kann Dir zum Flash-Problem leider nicht helfen, habe aber das gleiche Grundproblem.
FHEM liest die FB, die Steckdosen schalten und der Status in FHEM wird geändert, doch aus FHEM lassen sich die Dosen nicht schalten.

Habe die alternative CUL erfolgreich geflasht, aber das Verhalten ist gleich RX und TX LED gehen, die FB wird gelesen, aber aus FHEM heraus geht nichts.
Ich suche derzeit nach einem Fehler in der Verdrahtung  zwischen Arduino und RF1101 oder in der Initialisierung des RF in CULFW, da ich am Ausgang des Arduino mit einem Osziloskop Signale erahnen kann.  Vielleicht suchtst Du auch mal an dieser Stelle.

Gruß
RDK

josburg

Probier's mal wie hier beschrieben: http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress/?page_id=251

Vielleicht hilft das?


Gesendet von iPhone mit Tapatalk

littleswabi

Hallo Josburg, 

hilft mir jetzt nicht wirklich weiter. 

littleswabi

Ich muss das nochmal aufgreifen...  Hat wirklich keiner eine Idee?

Gruß Michael

Feuerdrache

Hi Michael,
hab mir das Problem nochmal durchgelesen, es liest sich so, als wenn der bootloader nicht mehr richtig "tickt". 
Das schnelle blinken deutet darauf hin, das der Arduino in einer Art bootschleife steckt. Wenn du zufällig einen zweiten Arduino hast, kann man den bootloader erneut Drauf "braten" in dem man den zweiten zu einem ISP macht.

Kannst du sagen wie schnell die led blinkt?

Gruß FD
FHEM auf Raspberry PI B2
- CUL V3.4 mit culfw 1.65 für HM
- nanoCUL mit culfw 1.66 für KOPP FreeControl

littleswabi

Hallo Feuerdrache,

ich habe mittlerweile auch raus gefunden, dass der Arduino wohl in dieser bootschleife steckt aber noch nicht wie ich das beheben kann :)

Die LED blinkt sehr schnell. Mehrmals pro Sekunde denke ich.

Kannst du mir erklären, wie man den Bootloader neu aufspielt?!

Gruß

Michael

billy-boy



Hallo littleswabi

Schau mal hier: https://sysexit.wordpress.com/2013/02/07/burning-a-bootloader-to-an-arduino-nano-using-another-arduino/

Ich hatte den gleiche Fehler nach dem Aufspielen der a-culfw. Die Datei ist irgendwie zu groß.

Funktioniert aber einwandfrei.

Gruß

Rainer




littleswabi

Hallo :)

vielen Dank für den Link. Das werde ich heute Abend einmal testen.

Grüße!