Hallo zusammen, vor einigen Tagen habe ich mir bei ebay das SunFounder Lab Mega 2560 R3 ATmega2560-16AU Board (http://www.ebay.de/itm/Neu-SunFounder-Lab-Mega-2560-R3-ATmega2560-16AU-Board-fur-Arduino-kompatibel-/151275549665?pt=Wissenschaftliche_Ger%C3%A4te&hash=item2338b9b3e1) gekauft und hatte vor es mit dem DIAMEX USB ISP-Programmer Stick für ATMEL AVR STK500, ebenfalls von ebay ( http://www.ebay.de/itm/DIAMEX-USB-ISP-Programmer-Stick-fur-ATMEL-AVR-STK500-ATmega-ATtiny-Controller-/270955420181?pt=Bauteile&hash=item3f16339a15 ) und BASCOM zu programmieren. Beim ersten einschalten hat die gelbe LED auf dem Board noch geblinkt ( Bootloader wartet auf USB ??? ) , als ich jedoch das Testprogramm eingespielt habe, hat sie nur noch geleuchtet. $regfile = "m2560def.dat" $framesize = 32 $swstack = 32 $hwstack = 32 $crystal = 16000000 Config Portb.7 = Output Led Alias Portb.7 Do Led = 0 Waitms 1000 Led = 1 Waitms 1000 Loop End Das einspielen mit BASCOM hat keine Störmeldung gebracht , ausser dass die ARDUINO.eep datei fehlt. Aber daran wirds wohl nicht liegen ??? Ich hab auch versucht die ARDUINO.hex mit Xload zu laden. Auch das ging ohne Störmeldung, jedoch leuchtet die gelbe LED immer noch. Auf der Seite http://www.engbedded.com/fusecalc/ wollte ich die Fusebits kontrollieren, jedoch bin ich mir da nicht ganz sicher was ich auswählen soll. Wenn ich den ATMega 2560 auswähle, kann ich in der Liste nur Ext. Crystal bis 8 Mhz auswählen. Ich habe aber einen 16 Mhz. Übersehe ich da etwas ? Habe ich einen Gedankenfehler ? Im Anhang sind die screenshots von den BASCOM Einstellungen und den Fusebits. Habe ich villeicht was falsch eingestellt ?
Angehängte Dateien:
-
settings.jpg
210 KB -
fusebits.jpg
200 KB
die gelbe LED liegt schon mal an PB7 soweit richtig, die ist mit einem OB Verstärker entkoppelt, daher leuchtet die auch wenn der Pin nicht H ist
Nimm mal einen anderen Pin und mach da eine LED mit Vorwiderstand drann. Ändere natürlich das Testprogramm ab.
Hallo Düsendieb, danke für deine schnelle Antwort. Ich habe es jetzt mit Anschluss 22 auf dem Board versucht. Sollte ja der Port A.0 sein. Die LED bleibt dort immer dunkel .... Hast du villeicht noch eine Idee ?
Kannst du den Mega256 auslesen, um sicherzustellen, dass der Programmer funktioniert? Kannst Du die Fuses auslesen? bzw sind das die ausgelesenen Fuses im Screen Shot? Ändere dass Programm in ein Port komplett auf Ausgang lade ox0f auf einen Port Dann hast Du kein Problem mit den Zeiten Keine Ahnung wie das in Bascom heißt
Hi, Du hast in den Fuses "Ext Crystal Osc." eingestellt. Reingefallen wie so viele schon. Das ist ein Oszillator, kein Quarz. Jetzt erwartet er am Xtal1 Pin einen Takt. Klassisch zerfused. Wenn Du einen Takt anlegst, kannst Du das ändern, ohne externen Takt geht da nix mehr. Wenn Du noch so ein Ding hast: Fuses auslesen und nur Fusebit 6 setzen, dann hast Du an E.7 den Takt. Den und Masse an Xtal1, dann bist Du wieder im Rennen. Kurze Strippen nehmen. Richtig gewesen wäre Full Swing Oscillator ... Crystal Osc. Dabei bedeutet Chrystal Osc der interne Oscillator für einen Quartz. Der schwingt ja nicht von alleine. Ganz nebenbei solltest Du bei Engbedded genau hinsehen. Da steht 8- MHz, also richtiger ausgedrückt >=8MHz. Für Crystal Osc. gilt das analog und wird auch im DB so beschrieben. Letztendlich geht es da nur um das Ckopt bit, mit dem der Oscillator auf Full Power (Full Swing) gestellt wird. Ansonsten: Das Ding kam ja mit dem Arduino Bootloader, die Fuses dürften also schon passend gewesen sein. Erst auslesen und dann nur ändern was Du wirklich verstanden hast. Du hast aber jetzt schon die so ziemlich einzige Möglichkeit getroffen, mit der man sich so richtig ins Knie schiessen kann. Ausser vielleicht die kleinen Tinys, bei denen man den Reset wegfusen kann. Es ist allerdings merkwürdig, daß Bascom keinen Fehler raushaut, das Ding dürfte eigentlich nicht mehr antworten. Vielleicht stimmt ja sonst noch etwas nicht und Du hast das Ding gar nicht zerfused. Gruß, Norbert
Angehängte Dateien:
-
oszi.png
790 KB
Norbert S. schrieb: > Es ist allerdings merkwürdig, daß Bascom keinen Fehler raushaut, das > Ding dürfte eigentlich nicht mehr antworten. > Vielleicht stimmt ja sonst noch etwas nicht und Du hast das Ding gar > nicht zerfused. > > Gruß, > Norbert Exakt das. Die Fuses sehen für mich noch komplett Original und unagetastet aus genau so wie sie auch im Auslieferungszustand auf einem entsprechenden Arduino Board vorhanden wären ... Arduino-Mega 2560 Boards, und damit auch dieser Nachbau, haben zwar einen 16 MHz Quarz auf dem PCB, aber dieser klemmt an dem kleinen Mega 16AU. Der Mega 2560 wird durch einen Keramik Oszillator befeuert... siehe Bild. Tut mir Leid, bei Bascom kann ich dir nicht weiter helfen. Aber das konnte ich so nicht unwidersprochen stehen lassen. Achso noch was: Das dein Board am Anfang geblinkt hat liegt daran, dass per Default auch auf Arduino Klonen das "Blink" Beispiel aufgespielt ist. PS: Wenn ich einen Screen von einem Photo mache, darf es dann auch mal PNG sein?
:
Bearbeitet durch User
Bernhard F. schrieb: > Der Mega 2560 wird durch einen Keramik Oszillator befeuert... siehe > Bild. Hi, das ist aber nach dem Schaltplan von der Arduino Webseite auch nichts anderes als ein Schwinger mit den Kondensatoren drin. Ein Resonator, kein Oszillator. Da ist im Schaltplan keine Versorgungsspannung dran, das kann also kein Oszillator sein. Frage an Viktor: Hast Du die Fuses angefasst oder nicht? Gruß, Norbert
Norbert S. schrieb: > Du hast in den Fuses "Ext Crystal Osc." eingestellt. > Reingefallen wie so viele schon. Das ist ein Oszillator, kein Quarz. > Jetzt erwartet er am Xtal1 Pin einen Takt. Das ist falsch, CKSEL3:0_SUT1:0 = 1111_11 ergibt: Crystal Oscillator, slowly rising power, 8.0 - 16.0MHz, externer Takt wäre CKSEL3:0 = 0000. Musst einfach in's Datenblatt schauen.
Hi, sorry, da hab ich Blödsinn geschrieben. Wie gesagt, Bascom hätte ja auch einen Fehler raushauen müssen. Also: Funktioniert die Erkennung des Controllers in Bascom? Wenn ja, ist er noch am Leben und es stimmt etwas mit der Software nicht. Falscher Pin oder Hardware kaputt? Gruß, Norbert
Noch eins: die Fuses können nicht aus dem Code des ATM2560 heraus verändert werden, ein Bootlader kann sie zwar lesen, aber nicht ändern. Das geht nur per ISP oder JTAG. Man kann sich also per Bootlader nicht aussperren, für Anfänger ein großer Vorteil des Bootladers. Nachteil ist, dass keine volle Kontrolle über die Einstellungen des µC möglich ist. Wurde der Arduino 2560 bereits einmal per ISP programmiert, dann ist der Bootlader platt, da er im Zuge des Flashens obigem Programms gelöscht wurde. Problematisch ist dabei, dass der Resetvektor, Fusebit High M, immer noch auf den Bootlader zeigt. Damit startet der µC in einen leeren Bereich und resettet laufend. Die Lösung ist zu versuchen, den Resetvektor mit der zuletzt verwendeten Programmiermethode umzustellen. Wenn bis zuletzt per Bootlader programmiert wurde, geht das nicht, da die Fuses damit nicht verändert werden können, da kann also auch nichts Negatives passieren. Wurde dagegen bereits per ISP programmiert, dann sorgt das Umstellen der Resetvektor-Fuse dafür, dass der eigentliche Programmcode gestartet wird.
Hallo zusammen und vielen Danke für eure Antworten. Leider hat mich das ganze jetzt noch etwas mehr irritiert. Also @Düsendieb : Ja , das Foto zeigt die aktuellen Fusebits. Ja ich kann den auch wieder auslesen, löschen und wieder einspielen. Geht alles supper. Keine Störmeldung. Das mit dem ganzen Port habe ich auch versucht, leider ohne Erfolg. @ Bernhard F. und Norbert S : Jetzt bin ich mir garn nicht mehr sicher ob den nun die Fusebits richtig sind oder nicht, den ich habe die Fusebits nicht angefasst. Ich habe "nur" das Testprogramm so wie beschrieben geladen. Auch die Erkennung des Chips funktionier in BASCOM. An der Software wird es wohl nicht liegen, hab es auch mit anderen Ports probiert...alles bleiben auf 0. Ob die Hardware defekt ist.... ich weiss nicht ... ist zwar neu aber kein Original ... Ich weiss noch nicht mal wie ich es testen soll ? Der Hersteller sagt ja, dass das Ding zu 100 % kompatiebel zu Arduino ist ... gibt es den da nicht eine Möglichkeit für sowas wie "Werkseinstellung" ??? @MWS : Meinst du also die Fusebits sind richtig ? Ich habe das Board direkt nach dem Kauf mit ISP beschrieben... Ich habe also nie etwas mit einem Bootloader dran gemacht.Was meinst du genau mit "....dann sorgt das Umstellen der Resetvektor-Fuse dafür, dass der eigentliche Programmcode gestartet wird." bzw. was kann ich jetzt dagegen machen ? Also das das der Bootloader weg ist nachdem ich mit ISP drauf war, war mir schon vorher bewusst, ich hätte nur gedacht, dass dann auch mein test Programm trotzdem drauf läuft... Danke nochmal an alle
Schau' auf Dein Fusebits.jpg, Du musst das "Fusebit High M" umstellen, das immer noch auf den nicht mehr vorhandenen Bootlader zeigt. Jetzt springt der uC beim Einschalten in's Nirvana, er muss jedoch an den Anfang Deines bereits geflashtes Programms springen.
MWS schrieb: > Schau' auf Dein Fusebits.jpg, Du musst das "Fusebit High M" umstellen, > das immer noch auf den nicht mehr vorhandenen Bootlader zeigt. Jetzt > springt der uC beim Einschalten in's Nirvana, er muss jedoch an den > Anfang Deines bereits geflashtes Programms springen. Hi, fängt der nach dem nicht vorhandenen Bootloader nachdem er da ohne was zu machen durchgerannt ist nicht wieder beim Start an? Ich meine es ist so. Sonst hätte ich mich so auch schon längst mal ausgesperrt. Also Fuse auf Bootloder gesetzt aber kein Bootloader da und nur nacktes Programm drauf. Das sollte eigentlich gehen. Gruß, Norbert
Warum schreibst Du da jetzt eigentlich lang rum, anstatt endlich die %#$#*&-Fuse zu ändern, damit's dann läuft? Du meintest, es sollte gehen? Meinst Du nicht, dass Deine Vorstellungen sich evtl. mit der Realität beißen, da's ja tatsächlich nicht geht? Der uC rennt in ungültigen Opcode, dann gibt's einen Reset und das immer wieder.
Ah, gerade gesehen, dass ich den Falschen angemeckert hab', nun denn, war dann nicht so gemeint. Dann eben die Auforderung an den TE, endlich die %#$#*&-Fuse zu ändern.
MWS schrieb: > Ah, gerade gesehen, dass ich den Falschen angemeckert hab', nun denn, > war dann nicht so gemeint. > > Dann eben die Auforderung an den TE, endlich die %#$#*&-Fuse zu ändern. Hehe... Ich glaube nicht, daß es daran liegt. Er sollte die Fuses erstmal lieber nicht anfassen. @Viktor: Probiere es mal mit AVRdude. Dann machst Du eine Textdatei auf und fügst Folgendes ein: -------------- @echo off C:\avrdude -p m2560 -c stk500v2 -B 10 -e -u -U flash:w:%1:r PAUSE -------------- Die speicherst Du dann als *.bat ab. Avrdude.exe und Avrdude.conf müssen auf C:\ liegen. Dann ziehst Du einfach im Explorer die *.bin Deiner Testsoftware auf die *.bat und Avrdude rennt los. Die Fuses werden damit nicht angepackt. Dann mal sehen was passiert - Screenshot machen! Gruß, Norbert
Norbert S. schrieb: > Ich glaube nicht, daß es daran liegt. Er sollte die Fuses erstmal lieber > nicht anfassen. Falscher Ratschlag, genauso wie vorher schone der "externe Takt", Du trägst wirklich nicht zur gefühlten Kompetenz des Forums bei. Es gibt da nichts zu diskutieren, BOOTRST (Fusebit High M) muss ohne Bootlader 1 sein, "1 Reset Vector = Application Reset", also unprogrammiert. Norbert S. schrieb: > Sonst hätte ich mich so auch schon längst mal ausgesperrt. > Also Fuse auf Bootloder gesetzt aber kein Bootloader da und nur nacktes > Programm drauf. Ich würd' raten nach Datenblatt zu arbeiten und nicht nach Mythen. Du sperrst Dich mit einem falschem Setzen des Bootvektors nicht aus. Alles was passiert ist, dass Dein Programm nicht arbeitet. Programmieren kannst Du trotzdem jederzeit wieder. Selbst wenn durch Zufall eine Fehlbedienung eines µC-Typs noch kein Fehlerbild zeigt, so ist das nicht übertragbar. Das sind unerlaubte Zustände, die zu allen möglichen Erscheinungen führen können. Hier führt's eben zu Dauerresets, der Flash ist an Stelle des Bootladers leer, leerer Flash trägt den Wert $FF. Schon mal die Opcodes der 8Bit AVR durchgesehen, was einem $FF entspräche?
Viktor Koch schrieb: > @ Bernhard F. und Norbert S : Jetzt bin ich mir garn nicht mehr sicher > ob den nun die Fusebits richtig sind oder nicht, den ich habe die > Fusebits nicht angefasst. Ich habe "nur" das Testprogramm so wie > beschrieben geladen. bootloder per ISP "wegprogrammiert" Fuse darf nicht mehr auf Reset zum Bootloader stehen, ist doch nicht schwer zu verstehen. Ich hatte den Fehler anders rum, Bootloader aufgespielt und der wollte nicht arbeiten weil ich dieses Bit nicht setzte, hier anders rum nach dem Reset darf er nicht mehr in den Bootloader Bereich springen. Dabei könnte man wenn der Bootloader schon weg ist auch gleich den reservierten Bootloader Bereich für Programm freigeben.
@Joachim B. und MWS : Danke !!!!! Fusebit High M war der Grund. Danke an alle nochmal !!!!
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.