ATMEGA32A-PU Programmierprobleme

Keine Ahnung. Beim Vergleich der Datenblätter von Mega32 und Mega32A konnte ich bezüglich der ISP-Programmierung keine Unterschiede finden. Sogar die ID-Bytes sind gleich (was ich persönlich für einen Fehler halte). Auch die ab Werk eingestellte Clock-Option ist gleich. Es sollte also funktionieren.

Apropos ID-Bytes: Kannst du wenigstens die auslesen? Vielleicht, wenn du den ISP-Takt verringerst?

Vielleicht Fakes? Bei entsprechenden Stückzahlen könnte es sich selbst bei dem geringen Preis eines Mega32A lohnen, Fakes zu verkaufen.

Am 13.07.2011 19:30, schrieb Heiko Nocon:

War zwar ein 328P, aber wird offenbar gemacht:

Die haben sie allerdings trotzdem verkauft:

Viele Grüße, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa

Naja, inzwischen ist der Kupferpreis ja erheblich gestiegen, falls die

32A des OP wirklich Fakes sind, werden sie auf jeden Fall einen anderen Inhalt haben als diese 328P ;o)

Nee, so wird das Kupfer aus China rausgeschmuggelt :-)

--
SCNR, Joerg

http://www.analogconsultants.com/

Ich könnte mir vorstellen dass der Clockeingang des a empfindlicher ist als das des normalen. Hast du vieleicht ein besonders langes Programmierkabel? Neuere Chips scheinen immer empfindlicher auf unsaubere clock-signale zu reagieren als ältere. Achte auch darauf dass im Zweifelsfall die Versorgungsspannung von Programmer und Target übereinstimmt

--
MFG Gernot

Hi Gernot,

Eigentlich nicht, vom USBprog bis zum ISP-Stecker sind es ca 20 cm. Ich werde es heute wohl mal mit meinem Ultraprimitiv-Paralelportprogger probieren.

Na ja, die Schaltung wird mit geregelten 5 V aus einem Netzteil betrieben und der USBprog vom USB-Port. Das sollte nun aber wirklich nichts ausmachen.

Ich werds heute jedenfalls mal mit nem anderen Rechner testen und mit meinem alten Paralellportprogrammer

Ich halt Euch auf dem Laufenden.

Marte

Hi Heiko,

So hätte ich das eigentlich auch erwartet.

Wenn ich wüsste wie? mit den ATMEGAs habe ich eigentlich selbst noch nie wirklich was gemacht. Bisher war ich eigentlich nur mit ATM7 unterwegs udn das auch mehr projektbegleitend als aktiv dran.

Also doch mal in die Röntgenkammer damit...

Marte

Am 13.07.2011 19:30, schrieb Heiko Nocon:

Das halte ich generell erstmal für eine gute Idee, grade wenn man nicht weißt, mit welcher Clocksource der AVR grade läuft.

HTH

Thorsten

Marte Schwarz schrieb:

Vielleicht hilft das Posting in

Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x6DA025CA

Am 13.07.2011 18:56, schrieb Marte Schwarz:

[...]

Wenn ich mich richtig erinnere ist die Clock ab Werk auf 1MHz interner RC-Oszillator eingestellt. Wenn der MKII jetzt mit mehr als 250kHz (Clock/4) arbeiten will (und das will er per default) ist das zu schnell und er findet garnichts.

Versuch mal den Takt vom Programmer runter zu setzen und damit die Clocksource des AVR passen zu setzen.

Gruß Oliver

Naja, bei werksneuen weiß man das ja eigentlich, denn die default Clocksource ist im Datenblatt spezifiziert. Beim Mega32A (genau wie beim Mega32 auch schon) ist es der interne Oszillator @1MHz. D.h. absolute Obergrenze für den ISP-Takt sind 250kHz.

Überhaupt: Die meisten AVRs kommen mit 1MHz default, man sollte also eigentlich erwarten, daß

Das Passt. Ich hatte nur gelegentlich Probleme bei 5 und 3.3 V Die 20 cm sind auch ok.

verwende mal probeweise avrdude mit dem Parameter -B 10

--
MFG Gernot

Am 14.07.2011 17:34, schrieb Heiko Nocon:

Hallo Christian,

Danke, das liest sich hoffnungsvoll. Mein Kollege war ernsthaft überrascht, wie schnell der Schreibvorgang mit dem USBprog ging. Er hatte das früher langsamer in erinnerung gehabt. Vielleicht hilfts ja. Heute Nachmittag wirds ausprobiert, gestern hats nicht mehr gereicht.

Marte

Hi Gernot,

auch das wird heute mal versucht. Vielen Dank bisher, ich halt Euch auf dem Laufenden.

Marte

Eben deswegen standen da gleich zwei "

Hallo zusammen,

also als erstes hatte ich heute eingegeben:

avrdude -c avrispv2 -p m32 -P usb -v -B10

worauf ich alles korrekt ausgelesen bekommen hatte und mich schon mal gefreut hatte. Danach hab ich dann

avrdude -c avrispv2 -p m32 -P usb -Uflash:w:xyz.hex:i -Uhfuse:w:0x...

eingegeben und hab mich gewundert, dass der klaglos beschrieben wurde. Übernimmt avrdude das -B10 irgendwo und merkt sich das? Ich habs dann (ich hatte ja 15 die ich brennen wollte) versucht auszureizen. -B2 ging nicht bei jungfräulichen ATMEGA32A-PU ab -B2.01 ging es zuverlässig. Wenn die Dinger dann mal gefläscht sind, dann geht auch -B0.5 noch, zumindest beim Verifizieren. Mach ich den noch kleiner, denn gehts zwar immer noch, aber es dauert wieder länger.

Fazit: Vielen Dank für den Tip. Sollte ich das Benedikt Sauter mal schreiben? Ist das ein Problem vom USBprog oder von AVRDUDE?

Nochmals Vielen dank an alle Mitdenkenden

Marte

Nein, Its-not-a-bug-its-a-feature. Ich kenne ganz wenige Anwendungen die auf 1 MHZ laufen und keiner programmiert gerne langsamer als nötig. Eine Tipp von der Software im Problemfall währe aber was wert.

Ob sich der Programmer den B parameter merkt weiß ich nicht. Ich könnte es mir aber vorstellen weil das eine Anweisung an den Programmer erzeut.

--
MFG Gernot

Sagt der Programmierer immer gerne...

Ja, sicher ist das nicht der übliche Fall für eine fertige Anwendung (wobei es aber auch durchaus fertige Anwendungen gibt, die mit nur 32kHz Uhrenquarz laufen).

Das ist aber nicht der Punkt. Der Punkt ist: um überhaupt erstmal eine Anwendung drauf zu bekommen, MUSS der Programmer mit dem dem Teil im Default-Zustand reden, denn erst nach zumindest ein wenig Reden kann es einen anderen Takt bekommen.

Deswegen kann und muß der Standard-Wert eines Programmers natürlich einer sein, der mit einem Target im Standard-Auslieferungszustand reden kann.

Alles andere ist ein Bug. Da hilft weder Schönreden noch das Argument, man könne es ja auch langsamer stellen. Denn, wenn man weiß, daß das Target nach der Erstprogrammierung schneller ist, kann man ja DANN (und erst dann) genausogut schneller stellen.