Hi! Ich habe eine Schaltung, auf der ich bisher den ATmega168PA verbaut hatte. Nun hat der Fertiger auf die gleiche Platine den ATmega168PB verlötet. Laut Datenblatt ist der ATmega168PB jedoch kein drop-in replacement für den ATmega168PA. Er hat nämlich auf Pin3 und Pin6 keine GND/VCC sondern neue Port-Pins PE0 und PE1. Dennoch dachte ich, dass ich ihn zumindest mit einem ISP genauso ansprechen können muss, wie einen ATmega168PA. Leider gelingt mir das nicht. Ich bekomme immer eine device signature 0x000000 zurück geliefert. Was könnte da schief laufen? Ich benutze keinen externen Quarz/Oszillator, 5V, AVR ISP mkII bzw. mySmartUSB light. Ich habe es schon mit avrdude (auch mit -F -B 22) und BASCOM probiert. Die Kommunikation klappt einfach nicht. Eigentlich müsste doch auch SCL über den ISP reichen, um den ATmega zu programmieren. Mit einem 168PB-Xplained kann ich kommunizieren. Der ATmega ist werksneu verbaut. Es kann also auch kein debugWire vorher aktiv gewesen sein. Kann es sein, dass dadurch, dass ich für den PA auf Pin3 GND und Pin6 VCC hatte, dies bei dem PB zu (Zer-)Störungen führt und er deshalb nicht funktioniert? Irgendwie kann ich mir das nicht so recht vorstellen, da ich ja auch Taster gegen GND oder VCC an die Port Pins klemmen kann. Ich habe auch schon probiert, VCC an Pin 6 wegzunehmen (Leiterzug weggekratzt). Das hat nix gebracht. Pin3 kann ich nicht wegnehmen, da das unter dem Chip weiter zu GND auf Pin5 und Pin 21 geleitet wird. Eigentlich dürfte das auch fast egal sein, da mit dem https://hobbyking.com/en_us/atmel-atmega-socket-firmware-flashing-tool.html ein Direktzugriff auf die Pins des Chips erfolgt. Nur leider funktioniert es eben mit diesem Kabel-Socket auch nicht. Ich habe auch schon drei weitere Platinen getestet (und dabei möglicherweise zerstört). Nun bleibt mir fast nur noch, den ATmega mal runter zu löten und separat zu testen. Oder hat jemand noch eine Idee? -- Viele Grüße, Mathias
Dreh mal die ISP-Frequenz runter (bei avrdude die Option -B gefolgt von der Periodendauer in us, z.B. -B 100 für 10 kHz). Möglicherweise ist die ISP-Freuqenz zu hoch (darf maximal 1/4 der CPU-Clock sein)
M. K. schrieb: > Dreh mal die ISP-Frequenz runter (bei avrdude die Option -B gefolgt von > der Periodendauer in us, z.B. -B 100 für 10 kHz). Möglicherweise ist die > ISP-Freuqenz zu hoch (darf maximal 1/4 der CPU-Clock sein) Okay, probiere ich aus. Danke für den Tipp. Nur warum sollte das beim PB werksseitig anders als beim PA sein?
Um mir nochmal Klarheit zu verschaffen: > Kann es sein, dass dadurch, dass ich für den PA auf Pin3 GND und Pin6 > VCC hatte, dies bei dem PB zu (Zer-)Störungen führt und er deshalb nicht > funktioniert? Irgendwie kann ich mir das nicht so recht vorstellen, da > ich ja auch Taster gegen GND oder VCC an die Port Pins klemmen kann. Das interessiert mich wirklich brennend.
M. K. schrieb: > bei avrdude die Option -B gefolgt von der Periodendauer in us, z.B. -B > 100 für 10 kHz Geht mittlerweile übrigens auch direkt: -B 10kHz
Also ich hab es probiert und es funktioniert nicht. Dann habe ich ein neues bisher spannungsfreies Board genommen, dort den ATmega168PB runtergelötet und probiert. Es geht auch nicht. Es kommt einfach keine Kommunikation zustande. Ich kann mir nicht vorstellen, dass die Dinger werksseitig so gefused sind, dass man mit ISP nicht flashen kann. Bei 15 Chips könnte ja mal einer kaputt sein. Nur alle? Für Plagiate ist es vermutlich auch noch zu früh, oder? Hat jemand vielleicht noch eine Idee?
Also wir haben jetzt sogar probiert, einen externen Takt an XTAL1 anzulegen. Auch das hilft nix. Es kommt einfach keine Kommunikation zustande. Seltsam ist nur, dass bei Verwendung von avrdude und verschiedenen Werten für die Parameter -B bzw. -i eine unterschiedliche device signature zurückgeliefert wird. Das ist dann mal 0x640000 oder 0x4c0000 oder auch andere Werte für das höchste Byte. Die anderen beiden Bytes sind immer 0. Heißt das, dass da doch eine Kommunikation stattfindet, nur noch nicht mit der richtigen "Frequenz"?
:
Bearbeitet durch User
Mathias W. schrieb: > Heißt das, dass da doch eine Kommunikation stattfindet, > nur noch nicht mit der richtigen "Frequenz"? Sieht mir irgendwie alles suspekt aus. Es gibt auch keine „richtige“ Frequenz, sondern höchstens eine zu hohe, und bei der reagiert das Target einfach nicht, weil es dann die Initialisierungssequenz nicht richtig liest. Langsamer werden kann man ziemlich beliebig.
Ich glaube mittlerweile auch, dass die Charge defekt ist. Im Datasheet steht ganz klar unter "10.2.1 Default Clock Source" drin: "The device is shipped with internal RC oscillator at 8.0MHz and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock. The startup time is set to maximum and time-out period enabled. (CKSEL = "0010", SUT = "10", CKDIV8 = "0"). The default setting ensures that all users can make their desired clock source setting using any available programming interface." Da das nicht funktioniert, müssen sie wohl defekt sein. So ein Mist!
Mathias W. schrieb: > Ich glaube mittlerweile auch, dass die Charge defekt ist. Ist eigentlich verdammt unwahrscheinlich, sofern sie nicht jemand per ESD geschossen hat. Wenn sie bei Atmel rausgehen, kannst du dich drauf verlassen, dass sie erstmal intensiv auf dem Tester auf Herz und Nieren geprüft worden sind.
An Stelle von Mega88 hatte ich testweise auch ein paar Mega88PB eingesetzt. Da gab es keine Probleme mit der Programmierung. Was man nicht machen darf, ist die "full swing" Sicherung zu setzen. Aber Du nutzt ja nur den internen Oszillator. Vielleicht zeigst Du Deine Schaltung, um zu sehen, was da die Ursache sein könnte.
Ich konnte das Problem lösen. Es liegt daran, dass der 168PB ein anderes Startverhalten als der 168PA hat. Nach dem Anlegen einer Spannung ist er nämlich nicht sofort per ISP kommunikationsbereit. Muss mal nachschauen, wo das stand. Ich verwende primär den "mySmartUSB light" zur Programmierung. Dieser liefert die Spannung beim Programmieren gleich mit. Entweder bricht die aus irgend einem Grund sofort zusammen oder wird wieder abgeschaltet, wenn keine Kommunikation mit dem Chip zustande kommt. Jedenfalls funktioniert es, nachdem ich eine feste externe Spannung anlege. Mit ist das auch schon aufgefallen, als ich das Xplained-Board getestet hatte. Deshalb hatte ich vorgestern auch schon mal eine externe Spannung angelegt. Nur muss ich da was übersehen haben, sonst wäre ich früher auf die Lösung gestoßen. Und bezüglich meiner Schaltung: Damit hat es überhaupt nichts zu tun, da ich einen Chip auch einzeln auf dem Tisch liegen habe und da das Problem auch auftritt. Wie gesagt, das Problem ist spezifisch für den 168PB; mit dem 168PA funktioniert es.
Man könnte auch sagen, dass das mySmartUSB light zu schnell versucht mit dem 168PB zu quatschen. ;)
Mathias W. schrieb: > Und bezüglich meiner Schaltung: Damit hat es überhaupt nichts zu tun, da > ich einen Chip auch einzeln auf dem Tisch liegen habe und da das Problem > auch auftritt. Ich habe auch einen Chip auf dem Tisch zu liegen: kein Problem! > Wie gesagt, das Problem ist spezifisch für den 168PB; mit dem 168PA > funktioniert es. Du bist mit Deiner Fehleranalyse wohl noch nicht fertig.
M. K. schrieb: > Man könnte auch sagen, dass das mySmartUSB light zu schnell versucht mit > dem 168PB zu quatschen. ;) Man könnte auch sagen, dass das Konzept, dass der Programmer das Target versorgt, eben Mist ist …
Jörg W. schrieb: > Man könnte auch sagen, dass das Konzept, dass der Programmer das > Target versorgt, eben Mist ist … Naja, das finde ich nicht generell unbedingt als Mist, muss aber auch gut durchdacht sein was wohl beim mySmartUSB light nicht der Fall ist.
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.