-         

Ergebnis 1 bis 10 von 10

Thema: AtMega8 wird mit SPI ausgabe nicht mehr am Programmer erkann

  1. #1

    AtMega8 wird mit SPI ausgabe nicht mehr am Programmer erkann

    Anzeige

    Hey hey,

    Ich hab ein gewaltiges Problem:

    Ich habe mit den RFM12 Modulen von Pollin experimentiert.

    Plötzlich funktionierte mein myAVR USB light Programmer nicht mehr. Er erkannte den AVR nicht mehr. Auch andere Controllertypen wie den AtMega48 erkannte der Programmer nicht mehr.

    Zuerst hatte ich die Vermutung, dass die Versorgungsspannung zu nieder sei, das war aber nicht der Fall.

    Dann hatte ich den RFM12 abgezogen und es nochmal versucht aber keine chance...

    Jetzt meine Vermutung: kann es sein, dass der AVR immer versucht irgentwas über den SPI zu senden, aber per ISP auch Daten in die andere Richtung kommen und das dann zu einem Konflikt führt?


    Auch der Hersteller vom myAVR USB light Programmer hat mir eine Supportbox für den Programmer empfohlen, aber diese erkennt den Programmer einwandfrei.

    Ich bin momentan sehr verzweifelt, kann mir vielleicht jemand helfen?


    Michael
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.04.2010
    Beiträge
    1.249
    Normalerweise wird der Controller vom Programmer immer resettet und dann erst geflasht oder was auch immer. So kann es eigentlich nicht sein, dass dein Code zu Konflikten führt.

  3. #3
    Stimmt ja, ich hab auch mal mit dem Oszi die Signale abgegriffen. Ich kann jetzt nicht sagen ob da alles richtig gesendet wird, aber dafür stimmten die Pegel...

    Vielleicht könnte der AtMega per SPI irgentwelche Befehle "in den Programmer hinenen" senden, so dass dieser evtl falsch arbeitet?
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    03.04.2005
    Beiträge
    181
    Hallo,

    der RFM12 darf nicht enabled sein, während des SPI Programmierens.
    Hast Du einen Pullup am am Enable des RFM12
    ->Programmer zieht RESET am AVR
    ->Alle Outputpins werden Tristate
    Nun muß der Pullup den RFM12 disablen
    ->RFM12 treibt nicht mehr auf MISO


    Bernhard

  5. #5
    Hey Bernhard,

    also deine Aussagen habe ich jetzt leider mal garnicht verstanden.. sorry?
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

  6. #6
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    03.04.2005
    Beiträge
    181
    Hallo,

    der RFM hängt normalerweise über SPI am AVR.
    AVR ist Master
    RFM ist Slave.
    Die Pins MOSI und MISO des AVR bilden den Hardware SPI Bus.
    Über diese Pins läuft auch das Programmieren mittels ISP (normalerweise).

    Während ISP benutzt wird, darf somit der RFM nicht auf den MISO Pin treiben, da er sonst die Kommunikation AVR <->Programmer stört.
    Deswegen darf der RFM zu der Zeit nicht aktiviert werden.
    Aktiviert wird er über Pin nSel = 0.
    An dem Pin hängt normalerweise ein AVR Outputpin, um den RFM gezielt ein oder auszuschalten.
    Während ISP ist dieser AVR Pin tristate, nSel floatet. Evtl floatet er auch auf 0=aktiv, und der RFM stört dann MISO.
    Deswegen brauchst Du einen Pullup an nSEL, um den RFM während der ISP Zeit sicher abzuschalten.

    Ich hatte letzens auch ähnliche Probleme und habe dann die Pullups nachträglich noch eingelötet.

    Bei mir war allerdings noch ein weiteres Problem da, der Resetpin des Programmers war zerstört, warum auch immer.

    Ob mich der Fehler wie oben beschrieben wirklich gestört hat, kann ich somit nicht mehr sagen. Mit Pullup ist es jedoch sicher richtiger

    Bernhard

  7. #7
    Hey,

    Ah ja jetzt wird mir so einiges klar das werd ich doch dann gleich mal ausprobieren.
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

  8. #8
    Hey, also das mit dem Pullup ist zwar eine super ergänzung nur bringt das ganze keine Lösung.

    Ich hab das Modul jetzt komplett entfernt und der AVR wird immer noch nicht erkannt.

    Irgentwie muss es doch an der SPI schnittstelle liegen, denn ich habe einen zweiten AVR mit dem gleichen Programm gefasht und der wird jetzt auch nicht mehr erkannt, vorher funktionierte er aber noch ...
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    03.04.2005
    Beiträge
    181
    Tja schade,

    dann mal die Standardfragen:
    Sind evtl die Fuses verstellt auf falsch Taktquelle, der Klassiker?
    Wer ist kaputt, der Programmer oder der der AVR?
    Wenn Du einen frischen AVR reinsteckst, kannst Du den beliebig oft auslesen?
    Wenn Du Programmierst, bist Du sicher, daß Du das richtige Hexfile und/oder Fusewert reinschreibst?
    Kannst Du mit Deinem Programmer in einer anderen Platine aus einem alten Projekt sauber programmieren?

    Hast Du noch eine zweiten Programmer zum Vergleichen im Zugriff?

    Bernhard

  10. #10
    Fuses sind richtig eingestellt.
    Einen neuen AVR hab ich leider nicht heir...
    ja ich bin mir 100prozentig sicher das ich die richtigen files schreibe..

    ich hab nier noch ein AVRNET Pollin Board. Diesen Controller kann ich mit meinem Programmer auslesen.

    Einen Gleichen Programmer habe ich mir von einem Freund besorgt. Dieser hat nur 1mal ausgelesen und dannach nie wieder funktioniert...
    michaelwuehr.de

    CNC - Bearbeitung
    3D - Druck
    Software

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •