Hallo zusammen
Ich schreibe an einem kleinen Programm (650 Bytes = 15% vom Flash) für
den ATMEGA48PA.
Ich hatte es auch schon öfters mit Burnomat, also AVRDUDE in das Flash
geschrieben, und es klappte auch immer.
Plötzlich kommt die Fehlermeldung
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.02s
avrdude.exe: Device signature = 0x1e960a
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will
be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex"
avrdude.exe: input file D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex auto detected as
Intel Hex
avrdude.exe: writing flash (1110 bytes):
Writing | ################################################## | 100%
1.97s
avrdude.exe: 1110 bytes of flash written
avrdude.exe: verifying flash memory against D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex:
avrdude.exe: load data flash data from input file D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex:
avrdude.exe: input file D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex auto detected as
Intel Hex
avrdude.exe: input file D:\Microcontrolerfiles
17.6.16\Drehscheibensteuerung\Drehscheibensteuerung.hex contains 1110
bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100%
1.88s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0240
0xb4 != 0xff
avrdude.exe: verification error; content mismatch
avrdude.exe done. Thank you.
Ich dachte als erstes an einen Defekten Controller, aber auch bei neuen
Exemplaren kommt obige Fehlermeldung.
Auch nach Neuinstallation von AVRDUDE geht es nicht.
Gruß Fritz
haderlump schrieb:> [...] Ich schreibe an einem kleinen Programm (650 Bytes = 15% vom Flash)> [...] avrdude.exe: 1110 bytes of flash written
also das würde mir als erstes zu denken geben ...
(nur mal so am Rande angemerkt)
> avrdude.exe: verifying ...> avrdude.exe: verification error, first mismatch at byte 0x0240> 0xb4 != 0xff> avrdude.exe: verification error; content mismatch>
Die Aussage ist doch klar und verständlich ... das Byte an der Adresse
(HEX) 240 soll 0xff sein, ist aber 0xb4.
Also wurde entweder ein falsches Byte geschrieben oder ein falsches Byte
gelesen.
Mein Tip:
Programmiere mal mit einer kleineren Geschwindigkeit in den Chip.
Ich hatte das mal, dass mein Programmer einen Ring-Puffer genutzt hat
und die Daten über die PC -> Programmer Schnittstelle schneller reinkam
als die Daten Programmer -> µC rausflossen. Also wurde der Puffer
überschreiben bevor die Daten korrekt in den µC geschrieben wurden und
damit wurde dann der falsche Inhalt in den µC geschrieben.
Danke für die Antwort.
Leider komme ich trotzdem nicht weiter.
jemand schrieb:> haderlump schrieb:>> [...] Ich schreibe an einem kleinen Programm (650 Bytes = 15% vom Flash)>> [...] avrdude.exe: 1110 bytes of flash written>> also das würde mir als erstes zu denken geben ...> (nur mal so am Rande angemerkt)>
Was würde dir zu denken geben?
jemand schrieb:> Programmiere mal mit einer kleineren Geschwindigkeit in den Chip.> Ich hatte das mal, dass mein Programmer einen Ring-Puffer genutzt hat> und die Daten über die PC -> Programmer Schnittstelle schneller reinkam> als die Daten Programmer -> µC rausflossen. Also wurde der Puffer> überschreiben bevor die Daten korrekt in den µC geschrieben wurden und> damit wurde dann der falsche Inhalt in den µC geschrieben.
Ich habe einen einfachen Programmierer (Pollin Evaluation Board.) Also
ohne Ringspeicher und so.
Es hatte ja bisher alles wunderbar geklappt, plötzlich geht es nicht
mehr.
Auch das Brennen andere Programme bringt den gleichen Fehler !!
Wo kann man denn die Programmiergeschwindigkeit einstellen, ich hab da
noch nichts gefunden.
haderlump schrieb:>>> [...] Ich schreibe an einem kleinen Programm (650 Bytes = 15% vom Flash)>>> [...] avrdude.exe: 1110 bytes of flash written>>>> also das würde mir als erstes zu denken geben ...>> (nur mal so am Rande angemerkt)>>> Was würde dir zu denken geben?
Wenn du sagst, das dein Programm 650 Bytes lang ist, der Programmer aber
behauptet, 1110 Bytes schreiben zu wollen, liegt der Schluss nahe, das
da etwas auseinanderläuft :-P
Das sollte dir zu denken geben...
Nö steht doch da! Normalerweise wird der Flash vor den schreiben
gelöscht. Der Vergleich scheitert da im Flash Fragmente von anderen
nicht gelöschten Daten vorhanden sind.
Marco H. schrieb:> Nö steht doch da! Normalerweise wird der Flash vor den schreiben> gelöscht. Der Vergleich scheitert da im Flash Fragmente von anderen> nicht gelöschten Daten vorhanden sind.
Der Flash wird doch vor DEM Schreiben gelöscht!
haderlump schrieb:> avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will> be performed
Wie können da noch "Fragmente von anderen nicht gelöschten Daten"
vorhanden sein?
Marco H. schrieb:> Wenn nicht geschrieben wurde entsteht das gleiche Problem. Z.Bsp> durch> setzen von Fuse Bits die das schreiben verhindern.
Dann würde AVRDude gar nicht schreiben. Tut es aber:
haderlump schrieb:> avrdude.exe: writing flash (1110 bytes):>> Writing | ################################################## | 100%> 1.97s>> avrdude.exe: 1110 bytes of flash written
Marco H. schrieb:> Normalerweise wird der Flash vor den schreiben> gelöscht.
Wird er doch.
> Der Vergleich scheitert da im Flash Fragmente von anderen> nicht gelöschten Daten vorhanden sind.
Wieso gibt es keinen blank check?
Gruß
Jobst
Stefan U. schrieb:>> Wieso gibt es keinen blank check?>> Ich würde sagen, weil der normalerweise nicht nötig ist.Normalerweise ist auch kein Verify nötig.
Und wie man hier sehen kann, ist er nötig.
Gruß
Jobst
> Normalerweise ist auch kein Verify nötig.
Genau, und normalerweise macht avrdude auch kein Verify.
> Und wie man hier sehen kann, ist er nötig.
Erzähle das mal den Chinesen. Die verkaufen sogar Müll in Massen, wo man
den Defekt bei einer äußeren Sichtkontrolle sehen würde.
Ein bisschen bin ich schon weiter gekommen.
Hier das Hexfile wie es vom Assembler erzeugt wird.
:020000020000FC
:10000000FFC0189518951895189518951895189576
:100010001895189518954EC1189518951895189516
:1000200018951895B9C1189518951895189518959B
:040030001895189572
:100200000FEF0DBF02E00EBF0CE304B90FE107B919
:10021000B4D002E00093000101E00093010100E08E
:1002200000E700936E0101E000936F0100E0BB273F
:10023000EE2466277894442751D047FF04C04F77B7
:10024000B42F7CD00AC0439A449A442747D047FF32
:10025000FACF74D04F77B42F21D0653009F4BDD0D8
:1002600044273CD047FF19C04F77B42FBE1589F003
:100270001B2F105D1E19103308F01053183108F0B1
:1002800004C0439A449A459A08C0439A4498459AB0
:1002900004C0503011F402D000C0DFCF50FD0895EB
:1002A00051600027009385000093840002E00093D2
:1002B0006F0008954498439855270B2FD0E0C2E073
:1002C000B7D00B1719F00B2FB9D045980027009322
:1002D0006F001895D0E0C0E0ABD008952A9A14D0F2
:1002E0002A982B9A11D02B982C9A0ED02C982D9AB4
:1002F0000BD02D98409A08D04098419A05D041984B
:10030000429A02D04298089547FD16C043954A99F3
:1003100013C043954B9910C043954C990DC043951C
:100320004D990AC043954E9907C043954F9904C013
:100330004395199901C008954068089504E0009319
:10034000890000270093880001E000938100089550
:10035000CF93DF930F93C22DD32D0991003011F06D
:1003600005D0FBCF0F91DF91CF9108951091C00080
:1003700015FFFCCF0093C6000895F89400E00093A9
:10038000C50000E40093C40008ED0093C10006E03E
:100390000093C20078940895F8940F930FB70F93C9
:1003A0001F933091C6006395623010F4132E0FC076
:1003B000633010F4232E0BC0643010F4332E07C0CA
:1003C000653010F4432E03C0663008F4532E1F919D
:1003D0000F910FBF0F9178941895012D02250325D9
:1003E0000425051517FC03C014FC17C00895C0E0D0
:1003F0001FD0102FC1E01CD027E02121021731F4BB
:10040000121521F4032D0F73E02E00C0662711246E
:1004100022243324442455240895042DC32DDD279C
:100420000DD0662711242224332444245524089512
:10043000F999FECFC1BDF89A00B508951F93F999B7
:10044000FECFC1BD00BD1FB7F894FA9AF99A1FBF3D
:0604500078941F9108954D
:00000001FF
Und hier das was vom AVRdude gelesen wird .
Ich nehme an, dass für das verifying das gleiche File herangezogen wird.
:20000000FFC0FFFF1895FFFF1895FFFF1895FFFF1895FFFF1895FFFF1895FFFF1895FFF
F76
:200020001895FFFF1895FFFF1895FFFF43C1FFFF1895FFFF1895FFFF1895FFFF1895FFF
F11
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FC0
:20006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FA0
:20008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F80
:2000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F60
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FDF
:20014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FBF
:20016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F9F
:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F7F
:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F5F
:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F3F
:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F1F
:200200000FEF0DBF04E00EBF0CE304B90FE107B9B4D002E00093000101E00093010100E
0B7
:2002200000E700936E0101E000936F0100E0BB27EE2466277894442751D047FF04C04F7
728
:20024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FBE
:20026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F9E
:20028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F7E
:2002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F5E
:2002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F3E
:2002E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F1E
:20030000429A02D04298089547FD16C043954A9913C043954B9910C043954C990DC0439
522
:200320004D990AC043954E9907C043954F9904C04395199901C008954068089504E0009
35F
:20034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FBD
:20036000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F9D
:20038000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F7D
:2003A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F5D
:2003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F3D
:2003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
F1D
:20040000121521F4032D0F73E02E00C06627112422243324442455240895042DC32DDD2
71E
:200420000DD06627112422243324442455240895F999FECFC1BDF89A00B508951F93F99
9FD
:00000001FF
Man sieht da kommt ganz was Anderes zurück. Auch bezüglich der
Formatierung.
Ich hab mal einen anderen (funktionierenden) Controller ausgelesen.
die ausgelesene Datei sieht ähnlich aus. Also viele FFFFFFF
Scheinbar wird der Controller hier fehlerhaft ausgelesen.
Gruß Fritz
haderlump schrieb:> Man sieht da kommt ganz was Anderes zurück. Auch bezüglich der> Formatierung.
Formatierung ist bei Intel HEX irrelevant.
> Ich hab mal einen anderen (funktionierenden) Controller ausgelesen.> die ausgelesene Datei sieht ähnlich aus. Also viele FFFFFFF
FF steht in allen leeren Flash-Zellen. Insofern ist es nicht
verwunderlich, wenn in einem teilgefüllten µC viele davon anzutreffen
sind.
> Scheinbar wird der Controller hier fehlerhaft ausgelesen.
Oder fehlerhaft geschrieben.
Ich tippe hier am ehesten auf ein Hardware-Problem. Du schreibst, das
ist ein Evalboard von Pollin. Welches genau? Wie programmierst du deinen
µC genau? (steckst ihn in eine Fassung auf dem Board, verbindest ISP per
Kabel mit dem Board, etc). Wie erfolgt die Stromversorgung?
Wenn Kontakte an IC-Fassungen ausgeleiert sind. Oder wenn ISP-Kabel zu
lang oder mit Wackelkontakt angeschlossen sind, kann alles mögliche
passieren. Dito wenn die Betriebsspannung nicht stabil ist. Oder
Abblockkondensatoren vergessen wurden. Die Kommunikation zwischen µC und
ISP-Adapter per SPI ist nicht gegen Übertragungsfehler gesichert. Wenn
da Daten verfälscht werden (egal in welcher Richtung) dann kommt Salat
wie oben dabei heraus.
Hattest du eigentlich schon mal die Geschwindigkeit runtergedreht?
Hallo,
die unterschiedliche Formatierung der Daten der beiden Hex-Dateien ist
nicht das Problem, aber wie sehr die Inhalte auseinanderklaffen.
Also die Datei mit den 16 Nutzdatenbytes pro Zeile wolltest Du rein
programmieren, aber danach kamen die Daten mit den 32 Nutzdatenbytes pro
Zeile wieder raus ?
Das bedeutet, sehr viele Stellen, an denen Daten stehen sollten
enthalten jetzt 0xff. Das ist also kein Fehler durch ein nicht
gelöschtes Flash.
[2,3,6,7,a,b,e,f,12,13,16,17,1a,1b,1e,1f,22,23,26,27,2a,2b,2e,2f,32,33]
Irgendwie ergeben diese Adressen ein Muster, oder ?
Daneben gibt es auch noch zusammenhängende Blöcke, die Daten enthalten
sollten, aber nur als 0xff gelesen werden.
Viele Stellen enthalten auch einen ganz anderen Wert als vorgegeben.
Adresse 0x0024 : soll 0xB9 / ist 0x18
Adresse 0x0025 : soll 0xC1 / ist 0x95
Adresse 0x002C : soll 0x18 / ist 0x43
Adresse 0x002D : soll 0x95 / ist 0xC1
Adresse 0x0204 : soll 0x02 / ist 0x04
Den Bereich 0x0440 ... 0x0455 hast Du scheinbar gar nicht ausgelesen.
Danke erst mal für eure Hilfe. ich bin ja nicht der Profi.
Die Hardware hab ich überprüft. Da gibt es keine Unterbrechungen.
An den Anschlüssen kann man die Signale mit dem Oszi messen.
Die Verbindung mit dem PC läuft über COM1. Die ISP Schnittstelle ist auf
dem Bord vorhanden.
Doch da fällt mir etwas anderes ein.
Ursprünglich war in der AVRDUDE.CONF nur der Controller ATmega48
vorhanden.
Ich habe aber ATmega48PA-PU
Dieser unterscheidet sich in der Signatur.
Ich habe dann den 48er Block kopiert, und hinter dem 48er Block wieder
eingefügt und umbenannt und die Signatur angepasst. Blockbegin bei Zeile
8168
Die anderen Werte habe ich nicht verändert.
Auch in der AVR9_Burn_O_Mat_config.xml habe ich diese Anpassung
vorgenommen.
Blockbegin bei Zeile 235
Ich hatte das schon früher mal gemacht, weil der 644P nicht vorhanden
war.
Lief einwandfrei.
Aber vielleicht müsste da noch etwas angepasst werden.
Ich hänge mal beide Dateien an.
Gruß Fritz
haderlump schrieb:> Ich schreibe an einem kleinen Programm (650 Bytes = 15% vom Flash) für> den ATMEGA48PA.haderlump schrieb:> avrdude.exe: Device signature = 0x1e960a
... ist weder ein ATmega48, ATmega48A oder ATmega48PA
Die ATmega48 unterscheiden sich bei der Programmierung bis auf die
Signature Bytes nicht voneinander.
Das zweite Byte in der Signature (96) besagt, dass es sich um ein
64k-device handelt.
Der ATmega644P hat diese ID.
Und der unterscheidet sich von ATmega48 in der Programmierung.
Du hast Dich selbst und uns verarscht.
Gruß
Jobst
Jobst
Ich will hier weder euch noch mich verarschen. Die Signatur habe ich
nicht erfunden, sondern wurde von AVRDUDE zurückgegeben
Device signature = 0x1e960a (probably m48pa-pu)
Stefan U. schrieb:> Besorge Dir mal eine aktuelle Version von avrdude. Ich benutze seit> einigen Monaten Versdion 6.3, da ist der m48p längst drin.
Ich habe den m48pa-pu und der ist auch nicht drin.
So, und nun wird es hinten höher als Vorn.
Das Programm im Controller scheint zu laufen.
Das Leben ist voller Wunder.
Ich melde mich wieder.
erst mal Danke
haderlump schrieb:> Device signature = 0x1e960a (probably m48pa-pu)
Nochmal:
0x1e96xx sind 64kByte-Controller - also probably not m48pa-pu - der
hat nämlich nur 4kByte. (Woher auch immer der Text in Klammern kommt)
haderlump schrieb:> Ich habe den m48pa-pu und der ist auch nicht drin.
Die Gehäuseform ist in der Signatur gar nicht kodiert. Ein m48pa-ccur
meldet sich also genau so. Und da es den m48 nur als pa und nicht als p
gibt (im Gegensatz zum m328, den es als p, jedoch nicht als pa gibt) ist
der m48p der Richtige: 0x1E920A
Und die ID steht bei Dir nicht. Sollte er aber ausgeben, wenn der m48p
daran angeschlossen wäre.
Gruß
Jobst
Könnte es sein, daß dein programmer nicht nur beim Lesen des Flash
Speichers sondern auch beim Lesen der Device-ID Übertragugsfehler macht?
Verhält er sich bei einem anderen für avrdude bereits bekannten µC auch
so?
So Leute
Ich bedanke mich hier an dieser Stelle noch mal herzlich für eure Hilfe.
Hier der Status Quo.
Das Programm läuft,
das Verifying geht nicht, ist mir aber letztlich egal.
Die Signatur ist laut Doku so wie Jost es geschrieben hat,
Es geht aber damit nicht, sondern nur mit der Signatur, die ich
verwendet habe. Egal! Hauptsache es geht.
Statt Fehlerbeseitigung eben Kompensation.
Ich habe in einem anderen (englischen) Forum gesehen, dass andere User
die gleichen Probleme hatten, ich bin also nicht der einzige "Doofe".
Gruß Fritz
haderlump schrieb:> Ich habe in einem anderen (englischen) Forum gesehen, dass andere User> die gleichen Probleme hatten, ich bin also nicht der einzige "Doofe".
Moin!
Hast Du mal einen Link dazu?
Gruß
Jobst
Dümmer geht immer!!!
Ich hab die ganze Zeit nicht bemerkt, das im Programierbord noch ein
644p gesteckt ist. Es war zwar kein Quarz drin, aber die fuses waren
noch nicht gesetzt. Deshalb war er auf internem Oscilator gelaufen. Dass
dann nur Mist rauskommt ist ja dann klar.
Also sorry nochmal, dass ich euch so unnütz belästigt habe.
Aber hab wieder was dazugelernt.
Gruß Fritz.
der haderlump schrieb:> das im Programierbord noch ein> 644p gesteckt ist
Was? Ein 40 Pinner ist aber wirklich nur schwer zu übersehen. Geh doch
mal bitte zum Augenoptiker deines Vertrauens :-)
der haderlump schrieb:> Ich hab die ganze Zeit nicht bemerkt, das im Programierbord noch ein> 644p gesteckt ist.
Ich habe Dir gesagt, dass dort ein 644p antwortet. Da schaust Du noch
nicht einmal nach?
Und das Problem hatten die in dem englischen Forum, von dem der Link
noch immer fehlt, auch alle?
Gruß
Jobst
Jobst M. schrieb:> Ich habe Dir gesagt, dass dort ein 644p antwortet. Da schaust Du noch> nicht einmal nach?
Er dachte: Das kannst Du stecken lassen...
der haderlump schrieb:> Ich hab die ganze Zeit nicht bemerkt, das im Programierbord noch ein> 644p gesteckt ist. Es war zwar kein Quarz drin, aber die fuses waren> noch nicht gesetzt. Deshalb war er auf internem Oscilator gelaufen. Dass> dann nur Mist rauskommt ist ja dann klar.
Öhm, du hast nen 40-Piner nicht gesehen? Respekt. Und dass da nur Mist
beim Verify raus kam lag nicht am internen Oszillator sondern schlicht
am falschen Chip. Ein 644p ist nun mal ein wenig anders als ein 48pa.
Und Jobst M. hatte dir auch gesagt, dass die Signatur zu einem 644p
gehört, spätestens da hättest du mal einen Blick auf den uC werfen
können, der dir da im Sockel steckt.
Dennoch danke, dass du dich noch zurückgemeldet hast und das Thema damit
abgeschlossen ist. Das nächste Mal einfach mal genauer hinschaut ;)
Ich habe ja schon geschrieben: Dümmer geht immer.
Ich hab ja selbst gedacht, mich trifft der Schlag. Ich mach seit rund 55
Jahren in Elektronik, aber das ist mir noch nie passiert.
Shit happens.
Nebenbei: Ich kenne jemanden, der sagte er müsse Zum Arzt wegen
Fersensporn.
Dabei hatte er sich nur einen Reissnagel eingetreten.
Gruß Fritz
