Probleme mit AVRDUDE

  • Probleme mit AVRDUDE

    Hi,

    ich hab immer wieder das Problem, wenn ich einen AVR auf Quarzoszillator umstelle, und der Quarz etwas schneller ist(aktuell 14,318MHz), daß ich anschließend mit AVRDUDE nicht mehr richtig per ISP drauf zugreifen kann. Erst wenn ich wieder einen langsameren Quarz(8MHz) einsetze, dann gehts wieder. Das nervt jedoch langsam, da ich nicht immer den Quarz gesockelt habe.
    Ich benutze das einfache Kabel mit den 3 Widerständen am Parallel-Port.

    Kennt jemand das Problem, bzw. woran kann das liegen?
    Wer die Ironie findet, darf sie behalten ^^
  • Bei Zugriffen auf den AVR über ISP ist der AVR SPI-Slave. Das bedeutet, dass der Master (sprich: PC) den Takt vorgibt, mit dem die beiden sprechen. Der AVR hat darauf keinen Einfluss, der kann höchstens zu langsam sein, da die Taktfrequenz des AVRs mindestens die 4-fache Frequenz der bitclock des Masters sein muss. Mit dem Parameter -B kann man diese Geschwindigkeit setzen.

    Ich vermute, dass der AVR generell mit dem schnellerem Takt Probleme hat, was sich hier in der ISP-Kommunikation manifestiert. Abhilfe: unter niedrigem Takt die Fuses auf "full swing" umstellen.
  • Kann ich mir nicht vorstellen, da die sonst problemlos funktionieren. Ich hab auch schon mehrere FUSE-Konfigurationen durchprobiert, ohne Veränderung.

    Das Verhalten hängt aber definitiv mit dem AVR eigenen Takt zusammen, sonst könnte ich ihn ja nicht wieder ansprechen, wenn ich den Quarz tausche.
    Wer die Ironie findet, darf sie behalten ^^
  • So, ich bin dem Problem inzwischen mit dem Oszi nachgegangen, und was mir auffällt, daß bei der Response vom AVR das 1. Bit fast verschluckt wird. Das erkennt AVRDUDE dann nicht, und somit geht die Übertragung komplett schief:

    Quellcode

    1. bitbang_cmd(): [ AC 53 00 00 ] [ FF FF A7 00 ]
    2. bitbang_cmd(): [ AC 53 00 00 ] [ 00 AC 53 00 ]
    3. avrdude: AVR device initialized and ready to accept instructions
    4. Reading | | 0% 0.00sbitbang_cmd(): [ 30 00 00 00 ] [ 00 30 00 00 ]
    5. bitbang_cmd(): [ 30 00 01 00 ] [ 00 30 00 01 ]
    6. Reading | ################# | 33% 0.00sbitbang_cmd(): [ 30 00 02 00 ] [ 00 30 00 02 ]
    7. Reading | ################################################## | 100% 0.01s
    8. avrdude: Device signature = 0x000102
    9. avrdude: Expected signature for ATmega32 is 1E 95 02
    Alles anzeigen


    Anstatt 53 wird hier A7 erkannt. Er sendet dann zwar den Enable nochmal, aber die Response darauf stimmt aus meiner Sicht nicht, da das AC normalerweise nicht geechot werden soll, lt. Datenblatt. Daher möglicherweise auch ein Bug im AVRDUDE.

    EDIT: Oben ist SCK und unten MISO.
    Bilder
    • TEK0017.jpg

      29,85 kB, 320×240, 25 mal angesehen
    Wer die Ironie findet, darf sie behalten ^^
  • kbr schrieb:

    So, ich bin dem Problem inzwischen mit dem Oszi nachgegangen, und was mir auffällt, daß bei der Response vom AVR das 1. Bit fast verschluckt wird.

    Der AVR wird mit 5V betrieben? Dann sorg doch mal dafür, dass die Signale vom Programmer auch 5V-Pegel liefern und bessere Flanken haben, so wie das auf dem Scope-Bild aussieht wird die High-Schwelle eines 5V-AVRs nur so gerade eben noch erreicht.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Nun das kommt durch die Widerstände für den Spannungsteiler zur SD-Karte, die drücken das Signal leider etwas runter, aber es sind immer noch ca. 2,5V, das sollte doch reichen. Es wäre blöd, wenn ich zum Programmieren jedes Mal die Widerstände ablöten müsste, aber ich kann es mal versuchen...
    Wer die Ironie findet, darf sie behalten ^^
  • kbr schrieb:

    Nun das kommt durch die Widerstände für den Spannungsteiler zur SD-Karte, die drücken das Signal leider etwas runter, aber es sind immer noch ca. 2,5V, das sollte doch reichen.

    Das reicht nicht. Damit der AVR (mal exemplarisch im mega1284P-Datenblatt nachgeschaut) bei 5V-Betrieb sicher einen High-Pegel erkennt muss die Spannung mindestens 0,6*Vcc sein, also mindestens 5 Volt. Für den Low-Pegel ist die Schwelle unterhalb dieser sicher erkannt wird 0,3*Vcc (also 1,5V), deine 2,5V sind also mitten im undefinierten Bereich. Wenn es geht hast du Glück, wenn es nicht geht dann gehts halt nicht.

    Es wäre blöd, wenn ich zum Programmieren jedes Mal die Widerstände ablöten müsste, aber ich kann es mal versuchen...

    Was auch immer du da zum Programmieren anschliesst scheint nur sehr schwache Ausgangstreiber zu haben.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    bei 5V-Betrieb sicher einen High-Pegel erkennt muss die Spannung mindestens 0,6*Vcc sein, also mindestens 5 Volt

    du meinst 3V.


    Unseen schrieb:

    Was auch immer du da zum Programmieren anschliesst scheint nur sehr schwache Ausgangstreiber zu haben.

    Onboard Parallele eines Standard-PC's.

    Hab die Widerstände abgetrennt, und Tatsache, jetzt funktionierts :thumbup:

    Jetzt nehm ich mir grad mein DAPA-Kabel vor, da sind je 1K Widerstände drin an SCK und MOSI, die werd ich nun durch 470R ersetzen, wie das meist auch gemacht wird, dann geht's bestimmt besser.

    EDIT: Oder doch mal ein gscheites Kabel mit 74LS244 bauen...
    Wer die Ironie findet, darf sie behalten ^^