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.
Guten Morgen, haderlump schrieb: > Wo kann man denn die Programmiergeschwindigkeit einstellen, ich hab da > noch nichts gefunden. Tipp: man schaue sich die gesamte Dokumentation von avrdude an: Command-Line-Options http://www.nongnu.org/avrdude/user-manual/avrdude_3.html
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?
Wenn nicht geschrieben wurde entsteht das gleiche Problem. Z.Bsp durch setzen von Fuse Bits die das schreiben verhindern.
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
> Wieso gibt es keinen blank check?
Ich würde sagen, weil der normalerweise nicht nötig ist.
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.
Stefan U. schrieb: > Genau, und normalerweise macht avrdude auch kein Verify. Öh, doch. Das musste schon gezielt ausschalten mit -V ;)
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
Besorge Dir mal eine aktuelle Version von avrdude. Ich benutze seit einigen Monaten Versdion 6.3, da ist der m48p längst drin. http://stefanfrings.de/avr_tools/avrdude-6.3-mingw32.zip
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?
Jobst M. schrieb: > Und da es den m48 nur als pa und nicht als p > gibt ATmega48P http://www.microchip.com/wwwproducts/en/ATmega48P
ATmega48P schrieb: > ATmega48P > http://www.microchip.com/wwwproducts/en/ATmega48P Okay, das war offensichtlich eine Wissenslücke. Er hat dennoch die selbe ID wie der PA und daher muss der PA mit dem 'Treiber' für den P funktionieren. Gruß Jobst
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
haderlump schrieb: > as Verifying geht nicht, ist mir aber letztlich egal. Wirklich sicher ? Ich glaube kaum...
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 :-)
Matthias S. schrieb: > Was? Ein 40 Pinner ist aber wirklich nur schwer zu übersehen. Geh doch > mal bitte zum Augenoptiker deines Vertrauens :-) Solche Dinge passieren beim Augenoptiker auch: https://www.youtube.com/watch?v=0tkpxsaBaRI
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 ;)
:
Bearbeitet durch User
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
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.