Hi Comunity, ich habe einen Arduino Mega 2560. Bisher lief er mit dem internen 8 MHz Ozillator. Jetzt wollte ich den externen 16 MHz Quartz als Quelle verwenden und habe per Fuse external Clock eingestellt. Aber jetzt funktioniert gar nichts mehr. Ich kann es auch per ISP-Programmer nicht mehr umstellen. Was kann ich jetzt tun? Danke schon mal.
Obs schrieb: > Jetzt wollte ich den externen 16 MHz Quartz als Quelle > verwenden und habe per Fuse external Clock eingestellt. Und warum stellst du "external Clock" ein, wenn du einen externen Quarz betreiben möchtest? Dann besorg dir mal irgendeinen Taktgenerator und schließ den an. Dann wird's auch wieder gehen.
Verwenden die arduinos nicht von Hause aus den 16 MHz quarz? Zumindest beim Uno ist es definitiv so.
Mike schrieb: > Und warum stellst du "external Clock" ein, wenn du einen externen Quarz > betreiben möchtest? Weil ich dachte, dass das so richtig ist :D Was hätte ich denn einstellen müssen? Low Power Crystal Oscillator oder Full Swing Crystal Oscillator? Was ist dann external Clock? Bekomme ich das auch mit dem AVR-Dragon hin? Harald schrieb: > Verwenden die arduinos nicht von Hause aus den 16 MHz quarz? Zumindest > beim Uno ist es definitiv so. Kann sein. Ich verwende aber auch nicht die Arduino-IDE und den Arduino-Bootloader, sondern arbeite direkt mit C, dem AVR-Studio und nem AVR-Dragon.
Na dann. Rtfm. Und wenn du's verbockt hast selber schuld. Wer lesen kann ist klar im Vorteil.
Obs schrieb: > Mike schrieb: > Und warum stellst du "external Clock" ein, wenn du einen externen Quarz > betreiben möchtest? > > Weil ich dachte, dass das so richtig ist :D > Was hätte ich denn einstellen müssen? Low Power Crystal Oscillator oder > Full Swing Crystal Oscillator? Was ist dann external Clock? Bekomme ich > das auch mit dem AVR-Dragon hin? > Harald schrieb: > Verwenden die arduinos nicht von Hause aus den 16 MHz quarz? Zumindest > beim Uno ist es definitiv so. > > Kann sein. Ich verwende aber auch nicht die Arduino-IDE und den > Arduino-Bootloader, sondern arbeite direkt mit C, dem AVR-Studio und nem > AVR-Dragon. Das ist dem Chip aber herzlich egal. Die Fuses sind für den externen quarz schon gesetzt.
Harald schrieb: > Das ist dem Chip aber herzlich egal. Die Fuses sind für den externen > quarz schon gesetzt. Nicht wenn ich sie im C-Code umsetze ^^ Hab grade mal geschaut und die XTAL1- und XTAL2-Pins sind ja nicht nach draußen geführt ... kann ich den Arduino jetzt noch retten?
http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf An den XTAL Pins hängt der Quarz... Ob Arduino oder C ist ziemlich egal. Nachdem der Arduino-Dialekt letztlich C-Code ergibt, der vom AVR GCC kompiliert wird... Und Fuses setzt man nicht im C-Code um, oder irre ich!?
Obs schrieb: > kann ich den Arduino jetzt noch retten? Ja, mit einem externen Taktsignal - von einem anderen µC erzeugen lassen, - das 1 kHz Signal vom Oszi, - die 44,1 kHz aus einem CD Player - aus 2 Transistoren oder 1-2 Logikgattern einen Taktgenerator bauen - von der Soundkarte ein Rechtecksignal erzeugen lassen - LPT Schnittstelle - Sekundentakt einer Quarzuhr ;-) Das ist kein Arduino, sondern ein ATmega2560
> > Das ist kein Arduino, sondern ein ATmega2560 Der TO schrieb von einem ARDUINO MEGA 2560 Board - und der ist kein Arduino??? Sofern du den Chip ATmega 2560 meinst - mea culpa
:
Bearbeitet durch User
Obs schrieb: > Harald schrieb: >> Das ist dem Chip aber herzlich egal. Die Fuses sind für den externen >> quarz schon gesetzt. > > Nicht wenn ich sie im C-Code umsetze ^^ Wie kommst du denn auf den Unsinn? > Hab grade mal geschaut und die XTAL1- und XTAL2-Pins sind ja nicht nach > draußen geführt ... kann ich den Arduino jetzt noch retten? Löte an dem Quarzanschluss, der auf XTAL1 geht, einen Draht an und lege da einen Takt an. Dann kannst du wieder mit ISP drauf zugreifen. Oder du bastelst dir einen JTAG-Adapter. Wird ja auch langsam Zeit. JTAG arbeitet mit seinem eigenen Takt. Die Fuses stellst du auf Full Swing oder Ext. Crystal. mfg.
Thomas Eckmann schrieb: > Obs schrieb: >> Harald schrieb: >>> Das ist dem Chip aber herzlich egal. Die Fuses sind für den externen >>> quarz schon gesetzt. >> >> Nicht wenn ich sie im C-Code umsetze ^^ > Wie kommst du denn auf den Unsinn? Man kann die Fuses auch direkt im C-Code einstellen:
1 | FUSES = |
2 | {
|
3 | .low = (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0), |
4 | .high = (FUSE_BOOTSZ0 & FUSE_SPIEN & FUSE_JTAGEN), |
5 | .extended = 0xff, |
6 | };
|
Aber spielt ja auch keine Rolle, ob ich es im C-Code mache oder mit nem Programmer wie dem Dragon... Tatsache ist ich habs verstellt und versuche jetzt es wieder hinzubekommen... >> Hab grade mal geschaut und die XTAL1- und XTAL2-Pins sind ja nicht nach >> draußen geführt ... kann ich den Arduino jetzt noch retten? > Löte an dem Quarzanschluss, der auf XTAL1 geht, einen Draht an und lege > da einen Takt an. Dann kannst du wieder mit ISP drauf zugreifen. > Oder du bastelst dir einen JTAG-Adapter. Wird ja auch langsam Zeit. JTAG > arbeitet mit seinem eigenen Takt. > > Die Fuses stellst du auf Full Swing oder Ext. Crystal. > > mfg. Danke, das hilft mir doch mal.
Obs schrieb: > Man kann die Fuses auch direkt im C-Code einstellen: das bringt aber nur was, wenn du anschließend das *.elf File flashst anstatt des *.hex. Die Fuses werden dabei immernoch vom Programmer gesetzt und nicht von deinem Programm im µC
Obs schrieb: > Man kann die Fuses auch direkt im C-Code einstellen: Man kann die Fuses NICHT im C-Code einstellen! Mit dem vom Compiler bzw. Linker erzeugten Hex-File kann man keine Fuses einstellen. Die einzige Möglichkeit beim Flashen des Controllers die Fuse- und Lockbits zu verändern, ist, wenn alles in einem *.elf-File gespeichert ist und die Programmierung mit diesem File gemacht wird. Ob es damit:
1 | FUSES = |
2 | {
|
3 | .low = (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0), |
4 | .high = (FUSE_BOOTSZ0 & FUSE_SPIEN & FUSE_JTAGEN), |
5 | .extended = 0xff, |
6 | };
|
geht, indem dass im elf-File landet, kann ich ich allerdings nicht sagen. Mag sein. Ich glaube allerdings kaum, daß du mit einem elf-File flasht. Aber auch das ist völlig unabhängig vom Programm. Das Flashen eines Hex-Files hat keine Auswirkungen auf die Fuses. mfg.
:
Bearbeitet durch User
chris schrieb: > das bringt aber nur was, wenn du anschließend das *.elf File flashst > anstatt des *.hex. Das .elf file ist als default eingestellt im Atmel Studio 6.1 Obs schrieb: > Nicht wenn ich sie im C-Code umsetze ^^ Warum machst du auch so einen scheiß? Selbst schuld! Erst informieren wie die Fuses gesetzt sind, und dann was machen... Der 16MHz Quarz ist da nicht aus spaß auf dem Arduinoboard drauf...
Kaj schrieb: > chris schrieb: >> das bringt aber nur was, wenn du anschließend das *.elf File flashst >> anstatt des *.hex. > Das .elf file ist als default eingestellt im Atmel Studio 6.1 Aber nicht zum Flashen. Das ist für den Debugger. mfg.
Wenn er eh alles besser weiss, dann soll ihm doch Google weiterhelfen... Echt, zuerst nicht informieren, sich null auskennen, aber alles besser wissen...
Thomas Eckmann schrieb: > Löte an dem Quarzanschluss, der auf XTAL1 geht, einen Draht an und lege > da einen Takt an. Man kann auch den XTAL1 Pin an den XTAL1 (Pin 1) vom ATmega16U2 löten und am besten auch dort belassen. Hier für einen UNO R3 gemacht: http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp7 Unter "automatischer Abgleich ..." mit einem Bild der Platine.
Harald Nagy schrieb: > Wenn er eh alles besser weiss, dann soll ihm doch Google weiterhelfen... > Echt, zuerst nicht informieren, sich null auskennen, aber alles besser > wissen... Was für eine überflüssige Antwort :D zu viel Zeit? Ich hab nur gesagt, dass man die Fuses aus dem C-Code einstellen kann mit den bereitgestellten Macros. Ich hab nie behauptet, dass das zur Laufzeit passiert. Und ja, ich flashe das .elf-File mit dem Studio. D.h. damit:
1 | FUSES = |
2 | {
|
3 | .low = (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0), |
4 | .high = (FUSE_BOOTSZ0 & FUSE_SPIEN & FUSE_JTAGEN), |
5 | .extended = 0xff, |
6 | };
|
kann ich sehr wohl die Fuses einstellen. Ich komme aus der Software-Ecke und kenne mich noch nicht so gut mit Hardware aus. Da der Quarz nicht innerhalb des ATmega sitzt, dachte ich rein intuitiv, dass ich ihn als external Clock einbinden muss. Das war der Fehler. Dank zumindest ein paar hilfreicher Antworten weiß ich das jetzt und werde versuchen einen externen Clock an XTAL1 dran zu löten.
m.n. schrieb: > Man kann auch den XTAL1 Pin an den XTAL1 (Pin 1) vom ATmega16U2 löten > und am besten auch dort belassen. Hier für einen UNO R3 gemacht: > http://www.mino-elektronik.de/fmeter/fm_software.htm#bsp7 > Unter "automatischer Abgleich ..." mit einem Bild der Platine. Ahh super ... das sieht machbar aus. Vielen Dank!
Noch als Ergängung aus der fuse.h:
1 | The Fuse API allows a user to specify the fuse settings for the specific |
2 | AVR device they are compiling for. These fuse settings will be placed |
3 | in a special section in the ELF output file, after linking. |
4 | |
5 | Programming tools can take advantage of the fuse information embedded in |
6 | the ELF file, by extracting this information and determining if the fuses |
7 | need to be programmed before programming the Flash and EEPROM memories. |
8 | This also allows a single ELF file to contain all the |
9 | information needed to program an AVR. |
Thomas Eckmann schrieb: > Kaj schrieb: >> chris schrieb: >>> das bringt aber nur was, wenn du anschließend das *.elf File flashst >>> anstatt des *.hex. >> Das .elf file ist als default eingestellt im Atmel Studio 6.1 > Aber nicht zum Flashen. Das ist für den Debugger. > > mfg. Wenn ich in Atmel Studio 6.1 oben in der Leiste auf "Device Programming" (Ctrl+Shift+P) und dann auf "Memories" gehe, steht da als default das .elf-File drin. Drücke ich an gleicher stelle auf "Program", wo wird da wohl auch das .elf-File auf den Controller geflasht (alles andere würde ja auch keinen Sinn machen.). Ich bin so dreist zu behaupten, dass diese Stelle der IDE nichts (zumindesten nichts offensichtliches) mit dem Debugger zu tun hat. ;)
Noch für die, die es interessiert: Ich habe das Problem jetzt per JTAG gelöst. Glücklicherweise hatte ich zuvor schon JTAG bei der MCU aktiviert und so konnte ich einfach die JTAG-Pins meines Dragons mit den JTAG-Pins des ATmega2560 verbinden, die beim Arduino Mega 2560 über die ANALOG-IN-Pins A4 bis A7 nach draußen geführt sind. Über JTAG habe ich dann die Clock Source mit dem Studio umgestellt und nun funktioniert es wieder wie zuvor. Danke noch mal für die Hilfe und insbesondere für den Tipp mit JTAG.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.