Ardunio Nano 3 compatible will nicht

fox4

Erfahrener Benutzer
#1
Hallo,

ich habe mir hier 2 Ardunio Nano Boards geordert.

Leider krieg ich diese nicht an den Start ....
Hab's auf W7, XP sogar auf nem Apfel versucht.
Im Gerätemanager wird der Anschluss (USB-Serial Port Com 6) angezeigt.
Die Treiber hab ich nach Anleitung installiert.

Im Arduino Manager hab ich den Nano w/ATmega 328 ausgewählt / COM 6

Beim hochladen blinkt die RX Led auf dem Board 3x kurz .. das war's dann auch schon.
avrdude: stk500_getsync(): not in sync: resp=0x00


ein gleichzeitiges drücken der Shift Taste beim hochladen ergibt dann :
avrdude: usbdev_open(): did not find any USB device "usb"

Hat jemand diese Dinger in Betrieb und könnte mir die "Einstellungen" mitteilen ?
 

Airpac

I'll be watching you ...
#2
Hi, bei mir wollte sich neulich ein UNO nicht über USB verbinden lassen. Problem war, dass der USB Treiber in einem gepackten Ordner im Arduino /driver Ornder lag. Entpackt - an gleicher Stelle lief die Installation dann ohne Probleme.

arduino-1.0.4/driver/Old_Arduino_Driver/

Vielleicht nen Versuch Wert.
 

fox4

Erfahrener Benutzer
#5
Hatte am WE wieder etwas Zeit mich um die Nano's zu kümmern..

@Bimmi
auf diesen Billig-Dingern hat es tatsächlich keinen Bootloader drauf !

Hab diese nun mit einem UNO neu geflasht.
Ich kann danach jedoch nur 1 mal ein Sketch hochladen .. dann muss muss der Bootloader wieder neu
geflasht werden !?
 

ripschemitkraut

schläft auf /dev/dsk/c0t0
#6
Normal ist das nicht, das man nur einmal den Sketch hochladen kann. Wenn Bootloader drauf ist, dann ist er drauf. Zumindestens bei meinem. Habe auch so einen und hatte das selbe Problem. Ein nachlöten der Lötstellen hatte es dann gebracht.
 

OlliW

Erfahrener Benutzer
#8
Normal ist das nicht, das man nur einmal den Sketch hochladen kann. Wenn Bootloader drauf ist, dann ist er drauf.
nur zur Info: doch kann passieren, z.B. genau dann wenn zwar der Bootloader drauf ist aber die Bootloader Fuses nicht gesetzt sind...

was passiert: ohne die BL Fuses wird bei Adresse 0000 gestartet, da kein Programm drauf ist, ist der Speicher bis zum Bootloader mit FF's voll, also Nops, d.h. beim Neustarten wird bei 0000 gestartet, der uC führt alle Nops brav aus, bis er zum Bootloader kommt, und diesen daher ausführt. Wird nun ein Programm geladen, dann wird beim Neustart NICHT mehr zum Bootloader gesprungen (weil ja die Fuses falsch sind und bei 0000 gestartet wird und nict an der BL Adresse), sondern gleich das Program ausgeführt

=> es muss nicht nur der BL drauf sondern auch die Fuses richtig gesetzt sein

Zu Lipoly: Ich und Freunde/Bekannte von mir nun schon öfter Probleme mit Zeug von denen, gerade auch damit das Arduinos erst "hergerichtet" werden mussten, mal geht's, mal muss nen BL neu geflasht werden, mal fehlenen beim Nano die Test-Verbindung am FTDI, etc pp... allerdings muss man auch "anerkennen" dass Lipoly die Arduinos u.A. deutlich billiger als so andere Shops verkaufen... (ist also der immerwiederkehrende "Konflikt" zwischen "billig" und "..." ;))
 

OlliW

Erfahrener Benutzer
#10
im Prinzip genauso wie du das mit dem Flashen des Bootladers hinbekommst, nur mit den "Befehlen" für die Fuses statt für den Flash

wie die Fuses für dein Board&Bootlader zu setzen sind, kannst du aus der board.txt Datei, welche die verschiedenen Arduino Boards beschreibt ablesen: http://code.google.com/p/arduino/source/browse/trunk/hardware/arduino/boards.txt. Es geht vorallem um die high und extended fuses... wenn du willst kannst du dich auch ums lock byte kümmern (ist aber nicht notwendig)

ich weis ja nicht wie du den BL geflasht hast, deswegen kann ich dir keine konkretere Antwort geben
 

fox4

Erfahrener Benutzer
#11
Hi Olli,

hab die Board's nach dieser Anleitung geflasht.

also mit WinAVR :

avrdude -p m328p -P com14 -c stk500v1 -b 19200 -F -v -v -e -Ulock:w:0x3F:m -Uefuse:w:0x00:m -Uhfuse:w:0xdd:m -Ulfuse:w:0xff:m

danach :

avrdude -p m328p -P com14 -c stk500v1 -b 19200 -F -v -v -e -U flash:w:ATmegaBOOT_168_atmega328.hex
 

OlliW

Erfahrener Benutzer
#12
dann brauchst du doch nur in boards.txt schauen und die Einträge bei den fuses (deine erste Komandozeile) richtig machen...

na, ich mach's dir schnell

avrdude -p m328p -P com14 -c stk500v1 -b 19200 -F -v -v -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xda:m -Ulfuse:w:0xff:m

wenn du soetwas wie z.B. http://www.engbedded.com/fusecalc zu Rate ziehst wirst du tatsächlich feststellen dass die BL Fuses völlig falsch waren... ;)
 

bimmi

Bruchpilot
#15
Na jetzt muss ich den topic hier nochmal hochholen.

ich hab jetzt echt alles versucht, aber ich kriegs nicht hin. Kann vielleicht nochmal jemand für "dummies" erklären wie man den nano ordentlich per usb nutzen kann?

Ich kann ohne Fehlermeldungen mit meinem ISP Programmer den Nano beschreiben. Aber sobald ich ihn nutzen will (nutze ihn für die owSilProg_blheli_firmware) nicht brauchbar. "v... Connection to owSilProg programmer FAILED!".

Das ist die Meldung wenn ich die Fuses schreibe:

Code:
C:\20130414>avrdude -p m328p -c usbasp -b 19200 -F -v -v -e -Ulock:w:0x3F:m -Uef
use:w:0x05:m -Uhfuse:w:0xda:m -Ulfuse:w:0xff:m

avrdude: Version 5.11.1, compiled on Oct 16 2011 at 17:19:54
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\20130414\avrdude.conf"

         Using Port                    : lpt1
         Using Programmer              : usbasp
         Overriding Baud Rate          : 19200
avrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
         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  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  36
00 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  45
00 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  45
00 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  45
00 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 : usbasp
         Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

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

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

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

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x05"
avrdude: writing efuse (1 bytes):

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

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

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

avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xda"
avrdude: writing hfuse (1 bytes):

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

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

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

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

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

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

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

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK

avrdude done.  Thank you.
 

OlliW

Erfahrener Benutzer
#16
Hallo Bimmi,

leider sind, auch wenn man gerne helfen wollen würde, Ferndiagnosen oft auch deswegen sehr schwierig, weil Information unvollständig ist (wer hat schon Glaskugeln), deswegen läßt sich ausser raten wenig zu sagen.

Da du mit ISP "rumspielst" gibt es grundsätzlich zwei Wege
1) mit Bootloader
2) ohne Bootloader

Welche Fuses gesetzt werden müssen hängt natürlich davon ab, ob man Weg (1) oder (2) geht. Wenn man Weg (1) geht muss natürlich auch noch der richtige Bootloader aufgespielt werden. Sobald man per ISP anfängt müssen also eine Kette von Dingen richtig gemacht werden damit das funktioniert.
Weg (1)
i) richtigen Bootloader per ISP flashen
ii) richtige Fuses per ISP setzen
iii) Firmware Hexfile per Bootloader flashen
Weg (2)
i) Firmware Hexfile per ISP flashen
ii) richtige Fuses per ISP setzen

dein problem kann also z.B. daher kommen, dass du keinen Bootloader benutzt sondern direkt die Firmwarehex per ISP geflasht hast, aber die Fuses fürn Bootloader benutzt oder deine Fuses nicht zum Bootloader passen, oder dass du zwar nen Bootloader per ISP geflasht hast, aber den falschen Bootloader benutzt, oder dass du die Firmware hex noch gar nicht geflasht hast, oder... oder... oder ... du siehst, lauter wenn und aber die Keiner ausser dir beantworten kann, und vorallem keiner aus der Ferne... :)
 

bimmi

Bruchpilot
#17
Hi Olli,

danke für Deinen Beitrag dazu. Ich hab mich doch etwas unklar ausgedrückt. Sorry. Normalerweise schreib ich ausführlicher, allerdings dachte ich mir, es gibt nur einen Weg und ich hab nichts falsch gemacht :D

Ich habe den selben Fehler wie der Thread Ersteller. "avrdude: stk500_getsync(): not in sync: resp=0x00". Ich hab mir ja den Nano bestellt damals, als ich meine Turnigy Plush Regler flashen wollte - das ich mit dem Tutorial auf Deiner Werbseite - erst mal herausgefunden hab, dass das mit denen auch möglich ist. :)

Ich hab dazu ja auch einen Komentar auf Deiner Webseite hinterlassen und Du hast mir den Tip ja schon gegeben mit dem "Hinweis". Soweit ich mich entsinnen kann war es ja die beiden Pins auf dem FTDI Chip miteinander verbinden und den Bootloader neu zu flashen. Ich hab die Pins miteinander verbunden, aber da ich mich mit nem Arduino zuvor noch NIE wirklich befasst hatte, hab ich aufgegeben und mir einen UNO zugelegt. Damit hat das auch super funktioniert.

Jedoch reizt mich das doch irgendwie und als ich dann hier von dem selben Problem gelesen hab, dachte ich mir ich versuch nochmal mein Glück.

Ich bin folgendermaßen vorgegangen:

1. Pins miteinander verlötet.
2. Meinen 6 Poligen ISP benutzt und in der Arduino (Windows) das NanoBoard ausgewählt, als Programmer USBASP ausgewählt und über Tools "Bootloader flashen" ausgeführt. Das hat soweit auch ohne Fehler funktioniert.
3. Versucht ihn über Dein AvrBurnTool_v101.exe erneut das passende HEX File zu überspielen, jedoch bleibt der Fehler.
4. Mir das KK Flashtool heruntergeladen und damit dann Dein HEX File über den USBASP zu überspielen. Das hat auch ohne Fehler funktioniert.
5. BLHeliTool_v120.exe ausgeführt, den NanoComPort ausgewählt und versucht ihn anzusprechen... Quittierung mit folgendem Fehler: "v... Connection to owSilProg programmer FAILED!"
6. Dann hab ihn versucht über den USBASP mit der Komandozeile anzusprechen: "avrdude -p m328p -c usbasp -b 19200 -F -v -v -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xda:m -Ulfuse:w:0xff:m" - was auch funktioniert hat ohne Fehler.
7. Wieder versucht ihn mit der Firmware und über Dein Tool AvrBurnTool_v101.exe das HEX File per USB zu überspielen.

Der Fehler "avrdude: stk500_getsync(): not in sync: resp=0x00" bleibt aber nach wie vor.

Ist der Nano denn nun kaputt? Oder bekomm ich ihn irgendwie zum laufen?

Ich werde jetzt folgendes versuchen:

1. Ich flashe den Bootloader mit dem ISP über die arduino.exe (Windows)
2. Ich setze die Fuses per avrdude.exe mit "avrdude -p m328p -c usbasp -b 19200 -F -v -v -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xda:m -Ulfuse:w:0xff:m"
3. Ich versuche nochmal dann per USB und über Dein Tool das Hexfile zu überspielen.

Mehr hab ich nicht gemacht.
 
Zuletzt bearbeitet:

Hoppla1

Neuer Benutzer
#19
Guten Tag
Ich stehe im Prinzip nun an der gleichen Stelle.
Ich kann den Bootloader mit USBTiny mit Avrdude auf der Kommandozeile oder mit dem Arduino-GUI brennen, auch die Fuses.
Er wird jedoch nur als USB-Com von der Systemsteuerung erkannt und lässt sich entsprechend nicht über die GUI beschreiben.
wäre mir soweit auch gleichgültig, wenn man irgendwo das compilierte Hexfile finden könnte um das dann zu brennen.

Ich bin wohl nicht alleine an einer Lösung interresiert ;)
Danke
 
Zuletzt bearbeitet:

schnellmaleben

Erfahrener Benutzer
#20
Hallo Hoppla1, Du meinst das Hex-File aus Deinen Arduino-Programm? Das liegt nach Verify oder Upload-(Versuch) im Temp-Ordner rum ($TMPDIR/build<irgendeinelangenr>.tmp/SkriptName.cpp.hex). Kann man dann auch raus kopieren und per Kommandozeile / avrdude direkt ohne Bootloader flashen.
 
FPV1

Banggood

Oben Unten