Hallo zusammen, ich scheitere gerade dabei, per ISP einen ATmega8 (TQFP-Gehäuse) zu programmieren. MISO regt sich nicht und der Programmer (avrdude über RS232 (bit-banging)) meldet daraufhin "AVR device not responding". Der Programmieradapter ist schon jahrelang im Einsatz und funktioniert problemlos an ATmega16, ATmega32 und diversen ATtinys. War damals in Elektor beim "MiniMegaBoard" dabei und hängt an einer echten (non-USB) RS232. Hier noch etwas mehr Hintergrundinformationen: Der Controller sitzt auf einer winzigen Brushless-Regler Platine und darauf läuft aktuell noch die Original-SW des Herstellers. Einige Sekunden nach Spannung ein "piepst" der angeschlossene Brushlessmotor als Zeichen, dass alles O.K. ist. Controller und SW laufen also (ich konnte ja auch noch keine ISP-Verbindung aufnehmen, so dass alles noch "original" ist). Der Takt wird über einen winzigen Quarz erzeugt (vermutlich 10 oder 16 MHz). Die Fuses sollten dazu passend programmiert sein, da die Original-SW ja läuft. Reset-Pin, SCK und MOSI arbeiten korrekt, nur MISO reagiert nicht. Nach dem erfolglosen ISP-Versuch kommt einige Sekunden später (gleiche Zeit wie nach Poweron) das Piepsen des Motors, das mir anzeigt, dass die SW wieder läuft - und das zumindest der Reset beim ATmega angekommen ist (zumindest RSTDISBL also nicht programmiert ist). Wenn ich den Reset manuell auf Gnd ziehe, dann initialisiert sich der Controller danach ebenfalls wieder und der Motor piepst. Fazit: Reset kommt "durch", SCK und MOSI funktionieren (Pegel ändert sich), nur MISO bleibt tot. => Kann der Hersteller die Fuses so "fies" programmiert haben, dass der Reset durchkommt, aber kein ISP mehr möglich ist? Selbst das Lesen der Signaturbytes - was so weit ich weiß immer gehen sollte klappt nicht. So komme ich nicht zum geplanten "erase device" um meine eigene SW einspielen zu können. Die Verkabelung des ISPs ist "solide", (MOSI auf MOSI, MISO auf MISO, SCK auf SCK, ...), die betreffenden Pins sind "durchgeklingelt", also keine Kurzschlüsse zu den Nachbarn und auch die internen Schutzdioden der Pins kann ich im stromlosen Zustand ausmessen, also auch kein Kurzschluß auf Vcc oder Gnd. Eigentlich alles O.K. - nur leider funktioniert's nicht und ich komme nicht weiter. Hat jemand eine kluge Idee? Gruß, Bernd
Man kann das programmieren über ISP per Fuse abschalten.
holger schrieb:
> Man kann das programmieren über ISP per Fuse abschalten.
Das könnte der Grund sein. Folgender Abschnitt im Datenblatt hat mich
fehlgeleitet:
"All Atmel microcontrollers have a 3-byte signature code which
identifies the device. This code can be read in both Serial and Parallel
mode, also when the device is locked."
Das heißt strenggenommen aber ja nur, dass man über die Lock Bits das
Auslesen der Signatur-Bytes nicht verhindern kann. Wenn man aber bei den
Fuse-Bytes "SPIEN" deaktiviert hat, dann ist es wohl egal, wie die
Lock-Bytes stehen, da SPI (ISP) ja schon totgelegt wurde.
Schade - ich dachte immer, dass ISP immer dann geht wenn RSTDISBL nicht
aktiviert ist und CKSEL nicht ganz im "Wald steht". Aber die beiden sind
wohl nur eine der Möglichkeiten für nichtfunktionierendes ISP.
Blöd, dass der Hersteller die Türe so gründlich verbarrikadiert hat,
denn ich will ja gar nicht an seine SW 'ran (schließlich gibt es
wesentlich bessere freie Software). Um die SW zu schützen hätte es doch
ausgereicht, die LockBits zu programmieren. Vermutlich hat der
Entwickler, der das gemacht hat gedacht "Sicher ist sicher".
Letztlich ist es nun sogar so sicher, dass mir der Aufwand für das
Auslöten und Einlöten eines neuen ATmega zu groß ist und ich lieber das
technisch etwas schlechtere Konkurrenzprodukt kaufe, bei dem ich meine
eigene SW dann per ISP aufspielen kann.
Gruß,
Bernd
Bitte 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.