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:
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?
Nachdem ich heute tagsüber das eine oder andere schalten konnte, funktioniert aktuell ein get ccconf schon wieder nicht mehr...
Es gab schon einige Leute, bei denen das Netzteil zu klein oder zu "unsauber" war.
Dann können die merkwürdigsten Phänomene auftreten.
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.
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.
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.
Zur Info:
Hatte neulich auch zwei "FTDI"-Nanos bestellt (eine Quelle, eine Lieferung!), von denen der eine sich nicht umprogrammieren lies (unter Linux (http://rtr.ca/ft232r/)) 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...
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.
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.
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.
Dann teste deine Geräte vorher ordentlich und behaupte nicht es hat keiner Probleme damit.
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.
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).
Das passt schon , habe udev-rules definiert ;)
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
Kann ja nicht schaden, den "normalen" Weg wie hier zu Anfang beschrieben auszuprobieren... :)
Zitatsduino: avrdude, ERROR: avrdude exited with error 256
Das FW-File wurde nicht gefunden - jetzt funktioniert es - warum auch immer