mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Fehler beim Brennen von ATMEGA48 mit AVRDUDE


Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Marco H. (damarco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: npn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marco H. (damarco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn nicht geschrieben wurde entsteht das gleiche Problem.  Z.Bsp durch 
setzen von Fuse Bits die das schreiben verhindern.

Autor: npn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso gibt es keinen blank check?

Ich würde sagen, weil der normalerweise nicht nötig ist.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Genau, und normalerweise macht avrdude auch kein Verify.

Öh, doch. Das musste schon gezielt ausschalten mit -V ;)

Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: fop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: haderlump (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ATmega48P (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Und da es den m48 nur als pa und nicht als p
> gibt

ATmega48P
http://www.microchip.com/wwwproducts/en/ATmega48P

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATmega48P schrieb im Beitrag #5110025:
> 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

Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marco H. (damarco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
haderlump schrieb:
> as Verifying geht nicht, ist mir aber letztlich egal.

Wirklich sicher ? Ich glaube kaum...

Autor: der haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Oberlajtnant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:


Youtube-Video "Harald Juhnke & Eddi Arent - Beim Optiker 1988"

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Oberlajtnant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: M. Köhler (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: haderlump (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.