Ich habs irgendwie geschafft mich aus meinem Atmega1280 auszusperren. Das Lockbyte ist auf 0x0C gesetzt, vermutlich durch eine fehlerhafte Kommunikation oder durch Blödheit des Bedieners, who knows. So ein 100 pin Teilchen kann ich auch nicht einfach auslöten und so an einen HV-Programmer stöpseln. Die andere Elektronik auf dem Board ist vermutlich auch nicht 12V Tolerant. Per ISP kann ich den Chip noch ansprechen (FUSEs und LB auslesen, device ID abfragen usw.), aber ich bekomme das LB nicht mehr geändert. Was da auf dem Chip drauf ist, kann, darf, und soll komplett gelöscht werden, was da neu drauf soll habe ich alles als source und binär in Reserve. Die anderen Fuses: L 0xFF, H 0xDE, E 0xFD Zur Verfügung habe ich: - Arduino ISP - USBASP (verschiedene) - AVRDude in beliebiger Version (vorbereitet ist 6.1 und 6.3) - Kabel und Adapter in vielen Varianten Könnte mir BITTE einer aufs Pferd helfen ich den ATMega wieder kooperativ bekomme?
Dieses Kommando musst du von deinem ISP-Programmer aus absetzen: Chip Erase (Program Memory/EEPROM) $AC $80 $00 $00
So, danke erstmal, das ist aber aus meiner Sicht erst der 2. wichtige Schritt, der sicher sehr hilfreich ist! Aber bitte lasst mich nicht auf halbem Weg verhungern, wie komme ich mit meinem Equipment zu dem Punkt das eingeben zu können?
Joe schrieb: > Aber bitte lasst mich nicht auf halbem Weg verhungern, wie komme ich mit > meinem Equipment zu dem Punkt das eingeben zu können? Wenn du Joe schrieb: > Per ISP kann ich den Chip noch ansprechen dann kannst du auch Chip Erase machen. Damit sind die Lockbits auch gelöscht.
:
Bearbeitet durch User
Sollte nicht ein ganz normales Programmieren ('flashen') reichen, dies
beinhaltet doch zu Beginn ein chip erase?
S. Landolt schrieb: > Sollte nicht ein ganz normales Programmieren ('flashen') reichen, dies > beinhaltet doch zu Beginn ein chip erase? Zumindest der Programmierdialog in meinem alten AVR Studio 4 macht da feine Unterschiede. Man kann einstellen, das kein Chip Erase vor dem Flashen neuer Firmware ausgeführt wird. Ob das sinnvoll ist? Keine Ahnung, es sind aber durchaus verschiedene Vorgänge.
Es gilt, ja man(n) kann nur Bits von 1->0 Programmieren. Also muss man immer den Chip vorher löschen.
Ansonsten kann ich noch den ersten Google-Fund anbieten: C:\> avrdude -p m88p -c usbasp -e (mutatis mutandis) Habe selbst aber keine Ahnung von Avrdude.
Na ja, das klappt aber nicht wie geplant: >avrdude -p m1280 -c usbasp -t avrdude> e >>> e avrdude: erasing chip avrdude> w lock 0 0x3f >>> w lock 0 0x3f avrdude (write): error writing 0x3f at 0x00000, rc=-6 avrdude (write): error writing 0x3f at 0x00000 cell=0x0c avrdude> d lock >>> d lock 0000 0c | | Und genau hier hänge ich.
Das Manual zu avrdude schreibt: > -e > Causes a chip erase to be executed. This will reset the contents of the > flash ROM and EEPROM to the value ‘0xff’, and clear all lock bits. Wenn also bei dir die Lockbits nicht gelöscht werden, solltest du z.B. die Bitrate der ISP Kommunikation verringern, z.B. mit dem -D <µs> Kommando. Die Voreinstellung ist 1µs, was bei einem MC der mindestens mit 4MHz getaktet wird, funktionieren sollte. Der Auslieferzustand der meisten AVRs is allerdings bei 1MHz Takt, so das ein Kommando a là '-D 5' hier sinnvoll ist. Edit: Ok, den Fusebytes nach hast du da einen Quarz dran. Wie schnell ist der denn?
:
Bearbeitet durch User
avrdude>avrdude -p m1280 -c usbasp -t -D 50 avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9703 avrdude> e >>> e avrdude: erasing chip avrdude> d lock >>> d lock 0000 0c | | avrdude> w lock 0 0x3f >>> w lock 0 0x3f avrdude (write): error writing 0x3f at 0x00000, rc=-6 avrdude (write): error writing 0x3f at 0x00000 cell=0x0c avrdude> d lock >>> d lock 0000 0c | |
Ich bin nach wie vor der Meinung, dass ein normales 'flashen' reicht. Alternativ: was passiert, wenn statt "... 0x3f" ein "... 0xff" gegeben wird?
Nochmal: auch für den ATmega1280 gilt wie für den Rest der Familie: "The Lock bits can only be erased to “1” with the Chip Erase command." Also: kleines Programm flashen und fertig. Mir ist ohnehin unklar, warum Sie ständig versuchen, die Lock-bits zu schreiben.
Danke für die Antworten, aber das war, ist mehrfach probiert, wenns so
einfach gewesen wäre, hätt ich hier kein thread gebraucht.
Jeder Schreibvorgang, einschließlich Chip erase, läuft ins leere. Ich
versuche nachfolgend einen Bootloader zu laden, passe die Fuses an und
setzte das Lockbyte auf 0x3f. Ganz nebenbei: selbst wenn ich das
schreiben der fuses und/oder des LB in nachfolgenden Kommando
unterlasse, ist das Ergebnis dasselbe, alle Varianten sind getestet. Ein
nachfolgendes Auslesen des chips ergibt nichts sinnvolles, da ja das
Lockbyte noch immer 0x0C ist und daher der chip "gesperrt" ist. Zudem
ist das Hfuse auch immer 0xDE, daher wird mein Bootloader nicht laufen,
denn der bräuchte 0xDA, was sich aber auch nicht setzen lässt.
Warum ausgerechnet LB 0x3f: Weil das laut Datenblatt halt "alles
erlaubt" heist, das hab ich nicht erfunden, die Bits 6&7 sind nach
Datenblatt immer 0 und können auch nicht gesetzt (ge-1st) werden.
Hier ein voller Output dazu:
avrdude>avrdude -c usbasp -p m1280 -P usb -b 19200 -B 0.5 -v -v -e -U
flash:w:"1280\ATmegaBOOT_168_atmega1280.hex":a -U lfuse:
w:0xFF:m -U hfuse:w:0xDA:m -U efuse:w:0xFD:m -U lock:w:0x3f:m
avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "\avrdude.conf"
Using Port : usb
Using Programmer : usbasp
Overriding Baud Rate : 19200
Setting bit clk period : 0.5
avrdude: seen device from vendor ->www.fischl.de<-
avrdude: seen product ->USBasp<-
AVR Part : ATMEGA1280
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
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 10 8 0 no 4096 8 0
9000 90
00 0x00 0x00
flash 65 10 256 0 yes 131072 256 512
4500 45
00 0x00 0x00
lfuse 0 0 0 0 no 1 0 0
9000 90
00 0x00 0x00
hfuse 0 0 0 0 no 1 0 0
9000 90
00 0x00 0x00
efuse 0 0 0 0 no 1 0 0
9000 90
00 0x00 0x00
lock 0 0 0 0 no 1 0 0
9000 90
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: try to set SCK period to 5e-007 s (= 2000000 Hz)
avrdude: set SCK frequency to 1500000 Hz
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.01s
avrdude: Device signature = 0x1e9703
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD
avrdude: erasing chip
avrdude: try to set SCK period to 5e-007 s (= 2000000 Hz)
avrdude: set SCK frequency to 1500000 Hz
avrdude: reading input file "1280\ATmegaBOOT_168_atmega1280.hex"
avrdude: input file
Y:\Arduino\MightyBoard\1280\ATmegaBOOT_168_atmega1280.hex au
to detected as Intel Hex
avrdude: writing flash (130838 bytes):
Writing | ################################################## | 100%
49.29s
avrdude: 130838 bytes of flash written
avrdude: verifying flash memory against
1280\ATmegaBOOT_168_atmega1280.hex:
avrdude: load data flash data from input file
1280\ATmegaBOOT_168_atmega1280.hex:
avrdude: input file 1280\ATmegaBOOT_168_atmega1280.hex auto detected as
Intel Hex
avrdude: input file 1280\ATmegaBOOT_168_atmega1280.hex contains 130838
bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100%
33.88s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x1f000
0x0c != 0xff
avrdude: verification error; content mismatch
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DE
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Ich hab mich jetzt nicht komplett ins Datenblatt eingelesen, aber kann es sein, dass Du ein Größenproblem hast? Das Ding ist ja rappelvoll! Zudem sind die Fuses zur Zeit auf einen 512 Word großen Bootloaderbereich eingestellt. Hast Du es testweise mal mit einem "etwas" kleineren Programm ausprobiert (..das vielleicht nicht 99,82 % des Flashs belegt)? Werner
.. Ach Sorry. Mein Denkfehler. Deine HEX-Datei ist so groß, weil der Bootloader-Bereich am Ende des Flash liegt, richtig? Ich glaube trotzdem, dass Du ein Größenproblem hast, was ggf. durch eine fehlerhafte Linker-Einstellung zustandekommt. Joe schrieb: > verification error, first mismatch at byte 0x1f000 0x1f000 ist doch genau die Startadresse des Bootloaders am Ende vom Flash, oder? Ich würde noch mal einen Schritt zurückgehen, und ein Blinky in den Controller flashen. Ohne Bootloader. Dann kannst Du wenigstens feststellen, meine Vermutung richtig ist. Werner
Werner schrieb: >Zudem sind die Fuses zur Zeit auf einen 512 Word großen >Bootloaderbereich eingestellt. würde ja gerne 0xDA setzen, aber nimmt er ja auch nicht an. > .. Ach Sorry. kein problem > > Mein Denkfehler. Deine HEX-Datei ist so groß, weil der > Bootloader-Bereich am Ende des Flash liegt, richtig? genau so > > Ich glaube trotzdem, dass Du ein Größenproblem hast, was ggf. durch eine > fehlerhafte Linker-Einstellung zustandekommt. Unwahrscheinlich: genau das funktioniert auf anderen (baugleichen) Boards > > Joe schrieb: >> verification error, first mismatch at byte 0x1f000 > > 0x1f000 ist doch genau die Startadresse des Bootloaders am Ende vom > Flash, oder? ganz genau, aufs byte. > > Ich würde noch mal einen Schritt zurückgehen, und ein Blinky in den > Controller flashen. Ohne Bootloader. > Dann kannst Du wenigstens feststellen, meine Vermutung richtig ist. gute idee! werde ich probieren und reporten! Danke!
Joe schrieb: > würde ja gerne 0xDA setzen, aber nimmt er ja auch nicht an. Vielleicht tut avrdude das nicht, wegen dem verification error. Schon mal versucht, nur die fuses zu programmieren, ohne was in den Flash zu schreiben? Also: avrdude -cusbasp -pm1280 -Pusb -e -Ulfuse:w:0xFF:m -Uhfuse:w:0xDA:m -U efuse:w:0xFD:m Werner
Oh ja, alle variation probiert. Nur flashen, mit und ohne erase (letzteres macht keinen sinn, aber einen versuch halt), jede fuse einzeln, jede kombiniation von 2 fuses, mit LB, ohne LB, mit erase vorher, ohne, alles was mir so eingefallen ist. im übrigen, Blinky alleine will auch nicht, verification error, nur halt vorne im flash. Es ist zum Mäuse melken mit dem 0x0C sagt mal, eine andere Theorie: wenn reset durch einen anderen Fehler im Board dauerhaft auf Low gezogen wäre, kann sowas die Symptome erklären?
Joe schrieb: > sagt mal, eine andere Theorie: wenn reset durch einen anderen Fehler im > Board dauerhaft auf Low gezogen wäre, kann sowas die Symptome erklären? Dann wäre er lediglich immer bereit zur Programmierung - ich denke nicht, das so ein Fehler diese Symptome erklären könnte, aber nachmessen des Signals an Reset ist ja möglich. Das die Betriebsspannung i.O. ist, setze ich einfach mal voraus. Da du ja deine Programmer mit anderen MCs getestet hast, vermute ich mittlerweile, das dieser Mega einfach kaputt ist. Kommt vor, ich hatte mal ne ganze Charge Mega8 (ein Glück nur diese ollen Dinger), die sich weder programmieren liessen noch auslesen noch fusen. Angeblich fabrikfrisch...
Scheint nach einem irreparablem Fehler im Flash... :-( Da hilft nur noch neues Zeug reinzulöten.
Stimmt denn die gelesene Signatur mit dem Datenblatt überein? Wenn nicht, dann sind alle anderen Aktionen sinnlos. Ich programmiere immer noch mit dem AS 4.19. Und als Programmer STK500 oder AVRISP mkII.
Peter D. schrieb: > Stimmt denn die gelesene Signatur mit dem Datenblatt überein? Joe schrieb: > avrdude: Device signature = 0x1e9703 Das passt zu einem Mega1280. Daran liegts also nicht.
Wenn tatsächlich das Lock-Bit-Byte auf 0x0C festgenagelt ist, wie behauptet wird, weshalb werden dann 130838 Bytes geschrieben und zurückgelesen, der erste Verifizierungsfehler tritt aber erst bei 0x1F000 auf, was, merkwürdig genug, in der Bootloader-Section liegt. Ich kenne weder USBASP noch avrdude, halte aber, bei aller Zurückhaltung, einen Anwenderfehler für das Wahrscheinlichste.
S. Landolt schrieb: > halte aber, bei aller > Zurückhaltung, einen Anwenderfehler für das Wahrscheinlichste. Ich auch (ganz ohne Zurückhaltung sogar ;-), bin aber irgendwie betriebsblind und finde meinen eigenen Fehler nicht, deshalb suche ich ja nach irgendeinem Geistesblitz (eigenem, fremdinduziertem oder fremden) hier im Forum. Neuen Mega einlöten, daran würde ich scheitern. 100 Pins SMD ist definitiv jenseits meiner Kompetenz und Fertigkeiten. Wenn ich das so einfach könnte, wäre auf jeden Fall günstiger einfach einen neuen Chip einzulöten (wäre dann aber ein 2560) statt nach einem Fehler zu suchen. Zudem will mir einfach nicht einleuchten warum der Chip defekt sein soll. Hat niemand was böses mit angestellt. Aber egal, wenn mir hier "defekt" gut genug begründet ist und "Anwenderblödheit" (nahezu) ausgeschlossen ist, dann werde ich das Board halt versenken (müssen). Solange aber noch die Chance auf eigene Blödheit besteht, bin ich für jeden zielführenden Hinweis dankbar (und DANKE an alle, welche hier bisher zielführend mitgegrübelt haben). Oder aber, ich finde einen Kompetzenträger, der bereit ist mir die 100+ Pins umzulöten. Am besten in der Nähe von MUC, dann kann ich möglicherweise kibitzen und dabei was lernen.
Wie die konkreten avrdude-Befehle aussehen, kann ich Ihnen leider nicht sagen, aber ich schlage folgendes Vorgehen vor: Auslieferungszustand herstellen, d.h.: - Chip Erase - Fuse-Low-Byte auf 0x62 - Fuse-High-Byte auf 0xD9 (abweichend JTAG disabled) - Extended-Fuse-Byte auf 0xFF Mit dem D9 ist auch BOOTRST ausgeschaltet, der kann zum jetzigen Zeitpunkt nur Verwirrung stiften. - Kleines Blinkprogramm 'flashen'. Die Lock-bits nicht anschauen und schon gar nicht versuchen, diese direkt zu schreiben (wozu auch?). Eventuell nach jedem Schritt die ganze Gerätschaft ausschalten - klingt nach Voodoo, zugegeben, aber manchmal geschehen Dinge, die sich einem nicht sofort erschließen. Alles mitprotokollieren und im Fehlerfall hier vorstellen, dann kann ein avrdude- und/oder ATmega1280-Kenner vielleicht weiterhelfen.
Hi, Wenn du willst kann ich mal mim JTAGICE 3 schauen ob es am USBasp liegt. Dazu musst du dich anmelden und mir ne PN schreiben wie wir das mit dem schicken machen. Wenn es nur um das einlöten eines TQFP100 geht könnte ich dir das auch machen , aber nur bleihaltig. Für das auslöten fehlt mir die Ausrüstung, bzw mit dem Lackdraht hab ich das noch nicht gemacht. Gruß JackFrost
Bastian W. schrieb: > Für das auslöten fehlt mir die Ausrüstung, > bzw mit dem Lackdraht hab ich das noch nicht gemacht. Den könnte man ja rundherum abknipsen. Habe ich mit zermanschten XMegas auch schon gemacht. Die Pins kann man dann runterschubsen und den neuen MC auf die vorverzinnten Pads mit Heissluft auflöten - oder mit der Lötnadel, wer sich den Spass machen will. Am besten vorher ein wenig Lötpaste auf die Pins, dann klappt das schon.
S. Landolt schrieb: > Wenn tatsächlich das Lock-Bit-Byte auf 0x0C festgenagelt ist, wie > behauptet wird, weshalb werden dann 130838 Bytes geschrieben und > zurückgelesen, der erste Verifizierungsfehler tritt aber erst bei > 0x1F000 auf, was, merkwürdig genug, in der Bootloader-Section liegt. Weil wahrscheinlich von 0x0000 bis 0x1EEEE nur 0xFF im hexfile steht, und das nach einem Chip-erase auch so im Flash wiederzufinden ist. Noch eine Anmerkung: Habe es nur überflogen, aber gibt es nicht irgendein Trick, dass es bei Verwendung eines Bootloaders zwei Locks gibt? Einen für den übrigbleibenden Flash und einen für die Bootloadersektion? Vielleicht ist da ein Problem. Ansonsten weiß ich jetzt auch nicht mehr weiter. Ich könnte dem TO höchstens noch beim Chip tauschen helfen. Um welche Region handelt es sich? Werner
Ich glaub ja nicht dran, daß der Chip ne Macke hat. Ich kenne mich allerdings mit Deiner Progger-HW,-SW überhaupt nicht aus. Ich würds mal mit original Atmel-Tools probieren.
Ich hatte mal ähnliches Phänomen.. Hatte den Bootloader Bereich zu klein gewählt und immer irgendwie versucht zu überschreiben.. ganz genau kann ich mich nicht mehr erinnern, als ansatz hilft das vielleicht. Das Mismatch rührt dann daher das die Überprüfung schon im Bootloader/Fusebereich oder umgekehrt anfängt.. was ja dann nicht mehr das Programm "matcht".
Hallo AFAIR hat ältere USBASP Programmer Firmware Probleme mit flash jenseits von 128k da1l6
da1l6 schrieb: > AFAIR hat ältere USBASP Programmer Firmware Probleme mit flash jenseits > von 128k Dann hätte es beim "Blinky" flashen ohne bootloader aber funktionieren sollten. Ich glaube nicht, dass der TO es geschafft hat, ein Blinky zu erzeugen, dass größer als 128 k ist. Es sei denn er macht parallel noch SETI@Home auf dem Mega. Werner
da1l6 schrieb: > Hallo > > AFAIR hat ältere USBASP Programmer Firmware Probleme mit flash jenseits > von 128k > meiner errinerung nach war es so das entweder Fischl programmer oder/und AVRDUDE irgendwann probleme mit chips mit mehr als 64k hatten.... ABER du schreibst doch weiter oben das es mit einem anderen (gleichen?) board funktioniert, oder hab i da was falsch 'ueberflogen' ? haste ein Oszi? mess mal was am pin XTAL2 rauskommt (Freq.?)
so, ein paar antworten: da1l6 schrieb: > AFAIR hat ältere USBASP Programmer Firmware Probleme mit flash jenseits > von 128k Korrekt, ich habe dahingehend nur neue. Und an anderen 1280 und 2560 chips getestet, das kann ausgeschlossen werden. S. Landolt schrieb: > klingt > nach Voodoo, zugegeben, aber manchmal geschehen Dinge, die sich einem > nicht sofort erschließen. Wenn Voodoo hilft mach ich auch Voodoo! S. Landolt schrieb: > ich schlage folgendes Vorgehen vor: > Auslieferungszustand herstellen, d.h.: > - Chip Erase > - Fuse-Low-Byte auf 0x62 > - Fuse-High-Byte auf 0xD9 (abweichend JTAG disabled) > - Extended-Fuse-Byte auf 0xFF > Mit dem D9 ist auch BOOTRST ausgeschaltet, der kann zum jetzigen > Zeitpunkt nur Verwirrung stiften. > > - Kleines Blinkprogramm 'flashen'. > > Die Lock-bits nicht anschauen und schon gar nicht versuchen, diese > direkt zu schreiben (wozu auch?). genau so probiert -> gleiche Situation. LB nicht berührt (weder gelesen noch geschrieben) Alles vorher auf "aus", einschließlich PC neu gestartet, just to be sure. Bastian W. schrieb: > Wenn du willst kann ich mal mim JTAGICE 3 schauen ob es am USBasp liegt. Super lieb das Angbot, ich befürchte aber das da keine Erhellung stattfindet, da alle meine (derzeit hier 5 liegenden) USBASP auf anderen 1280 und 2560 chips laufen. Teilweise sogar baugleiche Mainboards. Bastian W. schrieb: > Wenn es nur um das einlöten eines TQFP100 geht könnte ich dir das auch > machen , aber nur bleihaltig. Blei wäre mir wurscht, da nicht gewerblich. Werner schrieb: > Um > welche Region handelt es sich? Region München, Landkreis FFB Charly B. schrieb: > ABER du schreibst doch weiter oben das es mit einem anderen (gleichen?) > board funktioniert, oder hab i da was falsch 'ueberflogen' ? korrekt überflogen Charly B. schrieb: > haste ein Oszi? mess mal was am pin XTAL2 rauskommt (Freq.?) Habe mein Oszi ausgegraben und dabei meinen Logikanalysator gefunden. Werde das jetzt mal zum Einsatz bringen. Danke an Alle! Habe noch einige eurer Tipps abzuarbeiten und werde detailiert (soweit es mir möglich ist) berichten.
So Leute, nochmals Danke für de Unterstützung soweit, aber ich geb's jetzt auf. --> Blinky in's low Memory schreiben, H-Fuse passenden gesetzt, mit Chip Erase vorher, LB & andere Fuses untouched --> Fail --> Blinky in's BL Memory schreiben, so das keine Fuses angepasst werden müssen, mit Chip Erase vorher, LB & Fuses untouched --> Fail Beide Tests habe ich parallel auf einem baugleichen "known good" Board wiederholt, dort hat es jeweils funktioniert. Und auch dort habe ich jeweils VOR dem test fuses und LB so gesetzt wie es aktueller Sachstand auf dem fehlerhaften Board ist. Mit Logicanalysator (Saleae Logic, v1.2.10) Schreibvorgang sufgezeichnet, mit "gutem" Board vergleichen: ja es gibt kleine Unterschiede, imho und nach Datenblatt aber nicht relevant. SCL und MISO/MOSI Bit passen zusammen, für den Interessieten habe ich die beiden Captures mal angehängt (aus Grössenerwägungen nur ein einfaches Schreiben aller 3 Fuse Bytes), aber ich gebe das Board jetzt auf. XTAL mit Oszi messen habe ich mir gespart, da der Logicanalysator eine saubere two-way Kommuniktion ohne Ausreißer zeigt gehe ich von ordentlicher Taktung aus. Zudem habe ich nochmal alle anderen bereits getesteten Schreibversuche in allen anderen Kombinationen ausprobiert --> fail, ausgewählte Versuche habe ich auf dem good-Board jeweils erfolgreich durchführen können. Da ich den Chip nicht umlöten kann und das Board einen Neuwert von etwa 120 Euro hat, und der bisher getriebene Aufwand schon in keinem Verhältnis zum Wert darstellt (betrachte ich aber als gut investierten Aufwand für Ausbildung), gebe ich das Board jetzt auf. Nochmal Danke an alle Mitleser, Mitdenker, Vorschlags- und Hinweisgeber. Manches hat mir neue Denkrichtungen aufgezeigt und mir - auch wenn's im Ergebnis nicht erfolgreich war - weitergeholfen.
Bastian W. schrieb: > Ich kann dir den Atmega schon umlöten wenn der alte nicht überleben > muss. Bin sehr interessiert, wie kommen wir zusammen?
Das einfachste ist , du meldeset dich hier an und schreibst mir ne PN oder du postest hier deine Mailadresse. Den rest klären wir dann per Mail Gruß JackFrost
kannste mal ein bild posten wie es um dem atmega aussieht wg umloeten, event. koennte man mit einem anderen Progger versuchen ihn zurueckzusetzen VlG Charly
:
Bearbeitet durch User
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.