Hallo, ich habe einen ATmega64 und betreibe einen spi-bus damit. Zu testzwecken hab ich im SPI-Control-Register CPOL auf high gesetzt. Seit dem kann ich jedoch mit ISP keine verbindung herstellen. Kann das an diesem Register liegen? Wenn ja, gibt es dazu eine Lösung? Viele Grüße Alex
Mit anderen Worten es ist überhaupt völlig wurscht was im Gesamten SPI-Control-Register steht?
Hallo, völlig egal. Zumal beim Mega64 der ISP nichtmal auf den SPI-Leitungen liegt, wenn ich jetzt nicht irre. Gruß aus Berlin Michael
>Mit anderen Worten es ist überhaupt völlig wurscht was im Gesamten >SPI-Control-Register steht? Für ISP ist das egal.
Alex schrieb:
> Kann das an diesem Register liegen? Wenn ja, gibt es dazu eine Lösung?
Da ISP bei aktivem Reset arbeitet gibt es keine Beeinflussung.
Ärger kann aber das machen, was neben ISP noch an den betreffenden Pins
hängt. Wenn trotz Reset aktiv.
Es hängen tatsächlich noch LED-Treiber(max7221) an SCK. Möglicherweise gibt es da ein problem. vielen dank
Wenn die Pins imBetrieb Ausgänge sin eigentlich nicht. Eher wenn der Pin selbst im Betrieb ein Eingang ist, also draussen ein Ausgang sitzt. Wenn beispielsweise ein MAXe an der UART sitzt, die wenn ich mich richtig erinnere zwei der ISP-Pins beherbergt. Was m.E. eine eher seltsame Wahl von Atmel darsellt, glücklichrweise ist das bei anderen Modellen besser gelöst.
Hallo, ich habe vorhin den Controller rausgelötet und einen neuen eingelötet. CPOL auf high hat wieder die Wirkung, dass keine Programmübertragung stattfindnen kann.
Ich denke es liegt am SC Pin den du beschaltet hast, da dieser für ISP benötigt wird. Bau einen Jumper rein dann kannst du es zum Programmieren abtrennen.
An SCLK hängt seiner Aussage nach ein LED-Treiber-IC. Wenn er das nicht falsch oder über zu langes Kabel angeschlossen hat, dann entsteht mit ISP kein Konflikt. Aber ohne Schaltbild ist das alles reine Spekulation.
Angehängte Dateien:
-
controller.png
190 KB
Hallo, hier ist ein Bild von der Schaltung. Die Treiber die ich genannt habe, sind jetzt getrennt. Sowohl Spannungsversorgung als auch vom SCK. Trotzdem lässt sich der avr nicht programmieren. viele Grüße Alex
Woher stammt das Pinout vom ISP Anschluss? Von Atmel nicht, das ist mal sicher. Den versprochenden LED-Treiber kann ich nicht erkennen. Immerhin geht es auch darum, wo Konflikte entstehen können.
Hallo Magnus, bin mir nicht sicher was du meinst, jedoch sind alle benannten Netze verbunden. D.h. auch /Reset am ISP mit /Reset am Controller. Hardwarebedrahtung muss stimmen weil ich bereits programmiert hab. alex
Ok, das Rätsel des ISP-Steckers ist geklärt. Das Pinout stammt doch von Atmel, gehört allerdings zum JTAG Anschluss. So wird das aber nichts.
Die LED-Treiber habe ich ausgelötet, da ich diese als Problem ausschließen wollte. Der Schaltplan ist somit komplett.
Hallo, Alex schrieb: > Hallo Magnus, > > bin mir nicht sicher was du meinst, jedoch sind alle benannten Netze > verbunden. D.h. auch /Reset am ISP mit /Reset am Controller. Er meinte nur: es gibt 2 Varianten der ISP-Beschaltung, einmal die mit 6Pin (2x3) und einmal die mit 10Pin (2x5). Üblicherweise benutzt man eine der beiden, weil dann ein einfaches 1:1 Kabel zum ISP-Programmer passt. Die benutzen die üblicherweise ja auch. Deine Beschaltung passt nicht zum 10Pin-Standard, das kannst Du zwar machen, es irritiert aber eben etwas, weil Du da ja dann ein Spezialkabel gebaut haben mußt. Gruß aus Berlin Michael
Hallo A.K. Bei dem Programmieradapter handelt es sich um eine Eigenentwicklung meiner Hochschule. Und Funktioniert. Pinkompatibilität zu JTAG ist absicht. Nochmal: Das Programmieren des Controllers hat funktioniert, bis ich das Bit CPOL im SPI-CONTROL-REGISTER auf high gesetzt hab.
Dann wirst du wohl mit den Entwicklern des ISP-Programmers deiner Hochschule klären müssen, warum der Pegel von SCK ausserhalb vom Reset-Zustand diesen Programmer derart aus der Fassung bringt. Denn dieser Programmer funktioniert - wie du selber festgestellt hast - eben nur wenn SCK ausserhalb vom Reset-Zustand einen bestimmten Pegel aufweist. CPOL dreht diesen Pegel um und der Programmer streicht die Segel. Mit einem normalen Programmer sollte es funktionieren, vom Pinout mal abgesehen.
PS: Setzt du CPOL sofort nach dem Start und die Fuses sind vielleicht auch so eingestellt, dass trotz Quarz nicht erst 16ms gewartet sondern sofort losgelegt wird? Kannst mal ein bischen Wartezeit ganz vorne in main() einbauen, noch bevor du CPOL setzt, 1sec oder so, vielleicht hilft das. Alternativ kannst du CPOL nur während des SPI-Transfers setzen. Dann sollte auch kein Konflikt auftreten.
Kann es sein das du über einen Bootloader programmierst, da doch über MOSI und MISO statt über TX und RX programmiert wird. An meinen 6 poligen ISP Anschluß befindet sich zumindestens kein SS, TX oder RX.
Thomas O. schrieb: > Kann es sein das du über einen Bootloader programmierst, da doch über > MOSI und MISO statt über TX und RX programmiert wird. Du hast offenbar noch nie mit dem Mega64/128 zu tun gehabt.
ne habe ich auch nicht. Die ISP Schnittstelle sollte doch bei den großen AVRs über, SCK, MISO, MOSI, VCC, GND und RESET funktionieren. Hatte mir am Handy nicht die Mühe gemacht das Datenblatt runterzuladen und durchzusehen.
Hallo A.K., in den Fuses sind ich als start-up-time 64ms eingestellt und CPOL wird erst nach ca. 10 Zeilen initialisierung gesetzt. Ein delay kann ich im Moment nicht einbauen da ich ja nicht darauf zugreifen kann. zu Thomas: darf ich mal auf den Artikel verweisen: http://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use Besonderheiten bei TQFP64 Gehäusen PDI PDO usw. Frohe Botschaft an diesem Abend ist wohl das ich morgen ein JTAG-ICE bekomme und dann sehen wir mal weiter. viele grüße
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.