Fehlermeldung beim Signalduino flashen

Zook · 11 Juli 2017, 11:54:39

Hallo zusammen,

beim flashen des Signalduino bekomme ich folgende Fehlermeldung (am Ende):

Zitatflashing Arduino sduino
hex file: ./FHEM/firmware/SIGNALduino_nanoCC1101.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0
log file: ./log/SIGNALduino-Flash.log
sduino closed
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0 -p atmega328p -vv -U flash:w:./FHEM/firmware/SIGNALduino_nanoCC1101.hex 2>./log/SIGNALduino-Flash.log

--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/etc/avrdude.conf"

Using Port : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0
Using Programmer : arduino
Overriding Baud Rate : 57600
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : Arduino
Description : Arduino
Hardware Version: 2
Firmware Version: 1.16
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/SIGNALduino_nanoCC1101.hex"
avrdude: input file ./FHEM/firmware/SIGNALduino_nanoCC1101.hex auto detected as Intel Hex
avrdude: writing flash (20520 bytes):

Writing | ################################################## | 100% 5.52s

avrdude: 20520 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/SIGNALduino_nanoCC1101.hex:
avrdude: load data flash data from input file ./FHEM/firmware/SIGNALduino_nanoCC1101.hex:
avrdude: input file ./FHEM/firmware/SIGNALduino_nanoCC1101.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/SIGNALduino_nanoCC1101.hex contains 20520 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.13s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x36e6
0x98 != 0xe6
avrdude: verification error; content mismatch

avrdude done. Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino opened

Nutze ich den sduino dann zum schalten, funktioniert auch erstmal alles (Intertechno Steckdosen lassen sich schalten, Somfy Markise ebenfalls). Nach einiger Zeit hakt es dann aber gewaltig. Die Steckdosen lassen reagieren nur noch stark verzögert oder gar nicht mehr. Die Somfy Markise macht dann gar keinen Mucks mehr. Bei einem "get ccconf" in FHEM kommt gar nix - keine Rückmeldung, kein Pop-Up - nix.

Hier mal ein List auf den sduino:

Code Auswählen

Internals: 
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un: 
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@57600 
   DMSG       nothing 
   DevState   initialized 
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@57600 
   FD         13 
   LASTDMSG   nothing 
   NAME       sduino 
   NR         37 
   PARTIAL 
   STATE      opened 
   TIME       1499765977 
   TYPE       SIGNALduino 
   sendworking 0 
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 
   MatchList: 
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$ 
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+ 
     12:SD_WS   ^W\d+x{0,1}#.* 
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+ 
     14:Dooya   ^P16#[A-Fa-f0-9]+ 
     15:SOMFY   ^Ys[0-9A-F]+ 
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+ 
     17:SD_UT   ^u30#.* 
     18:FLAMINGO ^P13#[A-Fa-f0-9]+ 
     19:CUL_WS  ^K[A-Fa-f0-9]{5,} 
     1:IT       ^i...... 
     20:Revolt  ^r[A-Fa-f0-9]{22} 
     21:FS10    ^P61#[A-F0-9]+ 
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+ 
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8} 
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).* 
     5:CUL_TX   ^TX.......... 
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8} 
     7:Hideki   ^P12#75[A-F0-9]+ 
     X:SIGNALduino_un ^[u]\d+#.* 
   QUEUE: 
   READINGS: 
     2017-07-06 19:02:59   ITParms         Unsupported command 
     2017-07-11 11:49:54   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud) 
     2017-07-05 12:53:16   ccreg           C3E = 00 C0 00 00 00 00 00 00 
     2017-07-11 11:35:29   config          MS=1;MU=1;MC=1 
     2017-07-11 11:50:58   ping            OK 
     2017-07-06 18:59:11   raw             Unsupported command 
     2017-07-11 11:40:58   state           opened 
     2017-07-11 11:40:58   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50 
   getcmd: 
     cmd        ping 
   keepalive: 
     ok         0 
     retry      1 
   mcIdList: 
     10 
     11 
     12 
     18 
     43 
     47 
     52 
     57 
     58 
   msIdList: 
     0 
     1 
     13 
     14 
     15 
     17 
     2 
     22 
     23 
     25 
     3 
     32 
     33 
     35 
     38 
     4 
     41 
     51 
     55 
     6 
     68 
     7 
   muIdList: 
     13.1 
     16 
     20 
     21 
     24 
     26 
     27 
     28 
     29 
     30 
     31 
     34 
     36 
     37 
     39 
     40 
     44 
     44.1 
     45 
     46 
     48 
     49 
     5 
     50 
     56 
     59 
     60 
     61 
     62 
     63 
     64 
     65 
     66 
     67 
     8 
     9 
Attributes: 
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE] 
   hardware   nanoCC1101 
   icon       cul_cul 
   room       80_Vorratskeller,99_Intern

Hat jemand eine Idee, was ich falsch mache?

Zook · 11 Juli 2017, 22:32:43

Nachdem ich heute tagsüber das eine oder andere schalten konnte, funktioniert aktuell ein get ccconf schon wieder nicht mehr...

RappaSan · 12 Juli 2017, 09:14:50

Es gab schon einige Leute, bei denen das Netzteil zu klein oder zu "unsauber" war.
Dann können die merkwürdigsten Phänomene auftreten.

connormcl · 12 Juli 2017, 11:24:31

Was ist das denn für ein nano?

Die Fehlermeldung deutet ja zunächst drauf hin, dass der Speicher durch ist und du einen neuen nano brauchst.

Ansonsten hatte ich massive Probleme mit verschiedenen billigen China-Clones mit gefaktem FTDI-Chip. Die haben nach dem Einstecken erst mal einwandfrei funktioniert und dann in zufälligen Intervallen nach 5 Minuten oder auch zwei Tagen solche Aussetzer wie du beschreibst. Manchmal konnte man ein Reopen machen, manchmal half nur Reset durch Ausstecken.
Zumindest soweit ich das Messen konnte war der Fehler nicht die allseits bekannte fehlende Masse am Test-Pin, so dass ich die cul-Software im Verdacht hatte.

Allerdings ist die generelle Qualität der China-nanos wohl einfach zu schlecht, als dass es für den stabilen Dauerbetrieb geeignet sind. Hatte mir dann teure nanos für 8-9 EUR mit garantiert echtem FTDI-Chip von einem guten Händler aus Deutschland besorgt und die Probleme waren weg.

Zook · 14 Juli 2017, 08:15:28

Der ist von peterchen88 hier aus dem Forum. Ist ein NanoCul mit FTDI Chip...

Ich könnte mal den 868er CUL abhängen und dann nochmal versuchen zu flashen. Dann sollte eigentlich genug Saft da sein - hängt ja sonst nix dran.

gloob · 14 Juli 2017, 08:27:37

Was sagt denn der "Verkäufer" zu deinem Problem?
Ich hatte letztens auch so einen nanoCUL vom besagten User über umwege erhalten und habe es irgendwann aufgegeben. Der "Vorbesitzer" hat seine Zeit auch damit verschwendet und es auch nicht hinbekommen.

Beta-User · 14 Juli 2017, 08:47:55

Zur Info:

Hatte neulich auch zwei "FTDI"-Nanos bestellt (eine Quelle, eine Lieferung!), von denen der eine sich nicht umprogrammieren lies (unter Linux) und eine per Suchmaschine auffindbare Seriennummer hatte. Habe auch den anderen im Moment noch nicht im Einsatz, aber die beiden weiteren China-Nanos, bei denen die Neuvergabe einer USB-Identität geklappt hat und mir als MySensors-GWs dienen, scheinen auch dauerhaft zu funktionieren.

@peterchen88 (wenn Du hier mitliest): Vielleicht solltest Du auch eine entsprechende "Qualitätskontrolle" einführen, aber sei gewarnt, der Verkäufer war etwas "schwer von Begriff", was Ersatzlieferung angeht...

connormcl · 14 Juli 2017, 14:39:52

Falls das die nanoCULs sind, die auch auf Ebay verkauft werden als Standardausführung und Extreme mit Stabantenne, jeweils kompakt auf einer Platine, umhüllt von transparentem Schrumpfschlauch:

Diese hatte ich mir extra wegen der Aussage sie seien geprüft usw. gekauft, damit ich an der Stelle keinen Ärger mit der Inbetriebnahme von FHEM habe.

Leider hat sich herausgestellt, dass mein ganzer Ärger an allen Ecken und Ende genau mit diesen zu tun hatte...darauf basierende nanoCULs/Signalduinos sind leider nicht langzeitstabil und stürzen die ganze Zeit ab.

Es werden billigst China-Klones des Arduino Nano mit gefaktem FTDI Chip verbaut. Das Masseproblem ist wohl nicht vorhanden, aber sie haben alle die gleiche Seriennummer und sind wie gesagt nicht langzeitstabil und stürzen dann ab oder geben keine Daten weiter.
Oft muss man auch mehrfach flashen, weil der Flashvorgang mittendrin abbricht.

Habe die Arduino Nanos gegen hochwertige ausgestauscht und habe seitdem Ruhe.

gloob · 14 Juli 2017, 14:47:36

Schade das der "Verkäufer" trotzdem immer behauptet es seien ihm keine Probleme bekannt. Scheinbar gibt es viele Leute die Probleme mit den CULs haben.

peterchen88 · 14 Juli 2017, 15:32:19

Wenn jemand ein Problem mit einem CUL hat, kann er mich gern anschreiben. Ich schau mir das Teil gern an, um auch raus zu findenden was nicht in Ordnung ist. Leider schimpfen einige Leute sehr gern, aber es kommt nichts konstitutives raus. Mahl sind billige nanos schuld mal fehlende Spannungstteiler.

gloob · 14 Juli 2017, 17:50:26

Dann teste deine Geräte vorher ordentlich und behaupte nicht es hat keiner Probleme damit.

connormcl · 15 Juli 2017, 02:08:42

Zitat von: peterchen88 am 14 Juli 2017, 15:32:19
Wenn jemand ein Problem mit einem CUL hat, kann er mich gern anschreiben. Ich schau mir das Teil gern an, um auch raus zu findenden was nicht in Ordnung ist. Leider schimpfen einige Leute sehr gern, aber es kommt nichts konstitutives raus. Mahl sind billige nanos schuld mal fehlende Spannungstteiler.

Kann nicht sagen, was genau die Instabilität verursacht hat, sondern nur, dass sie nach Austausch der nanos gegen höherwertige mit echtem FTDI-Chip verschwunden sind. Es wurde jeweils die gleiche Software geflasht und identisch benutzt.

RappaSan · 30 September 2023, 12:48:12

Das device "/dev/ttySIGNALduino" kommt mir merkwürdig vor,
normal wäre sowas ähnliches wie "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0" (siehe erste Seite hier).

Rainer1 · 30 September 2023, 12:50:01

Das passt schon , habe udev-rules definiert

KölnSolar · 30 September 2023, 12:55:11

Sicher ?

Ich interpretiere

Zitat2023.09.30 12:28:39 3: sduino: StartInit, get version, retry = 0
2023.09.30 12:28:49 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2023.09.30 12:28:49 3: sduino: StartInit, get version, retry = 1
2023.09.30 12:28:59 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2023.09.30 12:28:59 3: sduino: StartInit, get version, retry = 2
2023.09.30 12:29:09 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2023.09.30 12:29:09 3: sduino: StartInit, get version, retry = 3
2023.09.30 12:29:09 2: sduino: StartInit, init retry count reached. Closed
2023.09.30 12:29:09 2: sduino: CloseDevice, closed

dass der Zugriff in die Hose geht.

Funktioniert denn der sduino abgesehen vom flashen ?

Grüße Markus