ATmega_8PB Trouble

[shaun]

Moin,

hat jemand von euch schon Probleme mit ATmega168PB bzw generell den PB-Typen gehabt?
Ich habe hier welche auf bestückten Platinen, aber auch separat Gekaufte (Farnell und Mouser), die sich merkwürdig verhalten.
Programmiert wird mit Atmel Studio 7, letztes Update bevor es Microchip hieß, und einem Atmel ICE (weiß) mit aktuellster Firmware via SPI.
Ub sind 5V, Kabel 20cm, Abblockkondensatoren vorhanden, Quarz 16MHz und 22pF, Reset hat keine weitere Beschaltung wie Supervisor-IC oder so.

Das Phänomen: Fuses setzen (v.a. CKSEL 1111 für Quarz 8MHz-, langsamer Start) klappt immer. Danach ist er meistens auch noch ansprechbar und der Quarz schwingt.
Nach dem Flashen des Flash-ROM funktioniert dann entweder alles und er ist weiterhin ansprechbar, oder es funktioniert, aber der SPI-ISP ist tot, oder der ganze Chip schweigt, inkl dem zuvor noch arbeitenden Oszillator.
Wiederbelebung mit 5V-Takt an XTAL1 bringt nichts.

Es ist auch nichts im Code, das den Reset-Pin und/oder die XTAL-Pins neu konfiguriert. Das Ganze ist mit verschiedenen Firmwares (3 Geräte) gleich oft passiert, mal geht es, häufig ist der AVR danach "bricked"

Das Internet kennt solche Berichte bezogen auf den PB, aber in den Threads dort stellte sich dann meist doch eine Fehlkonfiguration, Selbstbau-Programmer o.ä. als Ursache heraus.

Derselbe Code läuft auf einem 168PA sofort und ohne Probleme.

Und ja, die beiden VCC und GND Pins, die beim PB Portpins sind, habe ich entfernt.

Noch jemand eine Idee?
Ich habe noch 8 Multilayer mit je zwei 168PB hier liegen, die mag ich ungern auf 168PA umbauen müssen.

VG
Stefan

[he25rb]

Mach mal einen Versuch mit "Mini Core" für Arduino

mfg Herb

[ch_ris]

keine Ahnung von PB....etc. aber,
hast mal ohne bootloader probiert?
Fuses lassen sich dann noch lesen?

[virtexultra]

Kannst du BLB0 / BLB1 Bits bei den Fuses setzen? Also um auszuschließen das die Fuses irgendwie überschrieben werden. Du schreibst zwar das es vom Programm her ausgeschlossen ist, ich würde es aber überprüfen.

[shaun]

Moin,

ich nutze keinen Bootloader. ISP via SPI. Und nein, es lässt sich nichts mehr lesen, ISP ist tot, dito der Oszillator, der vor dem ROM-Flashen noch lief.
Auch externer Clock hilft nicht mehr. Es scheint auch so zu sein, dass das Flashen durchläuft, er beim Verify dann irgendwo (nicht immer an derselben Stelle) abbricht, wenn ich dann zurücklese bekomme ich nur 00h und nach dem nächsten Power Cycling ist der ATmega tot.

Den Zweck des Arduino-Cores verstehe ich nicht - als Test, eine von anderen erprobte Firmware zu flashen?

BLBx - kann ich probieren, ich kann ja die drei Fuse-Bytes von Hand eingeben im Flash-Tool vom AVR Studio.

[Bumbum]

Hallo,

ich habe die Datenblätter jetzt nicht verglichen, aber vielleicht werden die Fuses falsch gesetzt und der Reset disabled? Da gabs dann noch bei manchen AVR's die Möglichkeit per HV (High Voltage, ich glaube 12V) an den Reset zu gehen.

Viele Grüße
Andreas

[Chefbastler]

Hallo,

ich habe die Datenblätter jetzt nicht verglichen, aber vielleicht werden die Fuses falsch gesetzt und der Reset disabled? Da gabs dann noch bei manchen AVR's die Möglichkeit per HV (High Voltage, ich glaube 12V) an den Reset zu gehen.

Viele Grüße
Andreas

Für HV Programming brauchst auch den passenden Programmer zu um die Fuses wieder ändern zu können mit JTAG soweit in Erinnerung.

Würde nen neuen Atmega verbauen
Und mit den Fuses aufpassen den SPI nicht zu deaktivieren

[zauberkopf]

ich müsste mal gucken... ich glaube ich habe noch letztens nen avr dragon gesehen...
Der kann HV.
soll ich mal tauchen gehen ?

[Arne]

ich habe die Datenblätter jetzt nicht verglichen, aber vielleicht werden die Fuses falsch gesetzt und der Reset disabled? Da gabs dann noch bei manchen AVR's die Möglichkeit per HV (High Voltage, ich glaube 12V) an den Reset zu gehen.

Dazu als Ergänzung: Mit dem Atmel Studio 7 hab ich vor sechs Jahren auch gearbeitet. Da haben wir die Fuses direkt mit in den Code geschrieben, damit wir das nicht im Flash-Dialog von Hand machen mussten. Das wurde dann beim Flashen automatisch mit erledigt, ich erinnere mich dunkel dass es dazu ein Häkchen gab. Soll heißen: Hast du vielleicht irgendwo fest die Fuses im Code stehen? Bei uns war das eine fuses.h, die sah aus wie folgt. Der Inhalt lässt sich sicher auch an anderer Stelle irgendwie unterbringen, ohne separate Datei zwischen anderem Kleinkram versteckt.

Code: Alles auswählen

#ifndef FUSES_H_
#define FUSES_H_
#include <avr/io.h>

FUSES =
{
	.extended = 0xFD,
	//.high = 0xDF,			// Without JTAG
	.high = 0x9F,			// With JTAG
	//.high = 0x1F,			// With JTAG & debugging
	//	.high = 0xDC,			// Without JTAG, with chip45boot2 Bootloader
	//	.high = 0x1C,			// Bootloader & JTAG enabled
	.low = 0xFF
};

[shaun]

Moin,
nein ich habe keine Fuse-Definitionen irgendwo versteckt.
Das ist ein blankes Projekt, das ich from scratch selbst geschrieben habe. Wenn ich es in einen ATmega168PA flashe funktioniert es immer, wenn ich einen ATmega168PB verwende geht es in mehr als der Hälfte der Fälle schief. Ich konnte bisher noch nicht testen, ob ein uC der beim ersten Anlauf programmiert wurde und funktioniert, bei weiteren Flash-Vorgängen auch irgendwann aufgibt.
Für das Szenario - Oszillator steht still, kein ISP mehr auch nicht mit externem Takt - müssten ja schon einige Fuses falsch gesetzt sein, oder der Reset-Pin beim Start als Portpin konfiguriert sein. Dann müsste es aber immer zum Fehler kommen.

[zauberkopf]

Ich habe mal gerade PA und PB Datasheets verglichen.
Interessanter unterschied, die Stromaufnahme ist bei PB wesentlich geringer.
Das könnte so einiges mit sich ziehen.
z.B. die Pegel.. bei den Schnittstellen.
Eiernde Stromversorgung..

[Arne]

Hat der PB die gleichen Speicher- und Registeradressen sowie Speicheraufteilung wie der PA? Wenn nein, hast du den Controllertyp im Atmel Studio umgestellt (geht das?) und neu kompiliert beim Umstieg von PA auf PB? Nicht dass da Daten an Orte geschrieben werden, an denen sie nichts zu suchen haben. Gegen die Theorie spricht dass es manchmal geht und manchmal nicht...

Hast du die Fuse-Einstellung für 3-8MHz oder den internen Oszillator getestet?

[zauberkopf]

https://forum.arduino.cc/t/having-probl ... c/300859/5

[shaun]

Den Thread kenne ich, da geht es aber mehr darum, avrdude zu hacken, damit der die andere Signatur frisst.
Ich habe auch weitere Threads zum PB gefunden, aber bei denen stellte sich dann immer irgendwie raus, dass die CKSEL Fuses doch falsch waren.

Die Register sind soweit ich gesehen habe gleich, ich kann im Atmel Studio explizit auf den 168PB umstellen, das Binärfile ändert sich dadurch aber nicht.

Für mich sieht es so aus als würde der beim Schreiben des Flash bereits Schaden nehmen, zwischen Write und Verify wird er eher nicht so lange aus dem Reset gelassen, dass bei der Einstellung für slowly rising power der potenziell fuse-killende Code überhaupt läuft, und ich hatte Fälle, die nach dem Schreiben der Fuses (Crystal 8.0- MHz, slowly rising Vcc usw) auch mehrfach zu lesen gingen, aber beim Flash-Schreiben bereits im ersten Verify abgebrochen haben und danach bricked waren.

Ein Gerät bzw Prototyp habe ich neulich schnell noch auf einen 88PA umgelötet, aber meine Multilayer mit den vorbestückten 168PB würde ich gerne ohne Änderungen benutzen können. Ich habe noch eine weitere kleine Platine mit einem PB gemacht, evtl bestücke ich da mal nur den AVR, Abblock-C, Quarz mit Cs und den ISP Header und teste mal. Am besten gleich mit Chip Quik anlöten Oder zumindest nur die Pins, die ich für den test brauche

[zauberkopf]

Du.. das kann was ganz blödes sein...
wie z.B. zu hochohmige, oder niederohmige Pullup Widerstände im Programmer.

Oder ne wackelige stromversorgung.. z.B. der avr-dragon.. (alte information, kann falsch sein) sollte bei HV-Programmierung unbedingt extern versorgt werden, weil er sich sonst selber zerlegt.
Wenn Du magst.. ich wollte ich dieses WE für nächste woche hier durch lager gehen, und mal gucken, was weg kann.
Wenn ich den avr-dragon finde : Wäre er was für Dich ?

Ansonsten andere Idee : Programmiere dir doch mal auf die Schnelle mit nem anderen Atmel (arduino) dir ein 2. ISP Programmiergerät. Und mach den ganzen versuch dann damit + avrdude.

[zauberkopf]

Edit : Wegen des geringen Stromverbrauchs...
Ich erinnere mich gerade warum ich das geschrieben habe : Das Problem hatte ich nämlich mal, das ein neueres Bauteil so wenig strom verbraucht hat, das der Spannungsregler ins Schwingen kam.
Abhilfe hat dann hier erst mal quick and dirty ein 2. Widerstand...

[Finger]

Darf ich dir den Forte von Asix nahelegen? Der macht auch bei schwierigen Fällen immer einen schlanken Fuß. Ich hab den samt seinen Vorgängern seit 20 Jahren vielfach im Einsatz. Mir scheint tatsächlich, das du da Probleme mit deiner Programmierhardware hast....

[shaun]

Moin,
danke für den Tipp.
Eigentlich würde ich ja davon ausgehen, dass ein Programmer des Herstellers, der mit der Firmware versorgt wurde, die den Problemchip explizit einschließt, funktioniert.

Der Forte hat ja auf dem Papier überzeugende Werte gegenüber dem Presto, ausleben kann er die aber natürlich nur, wenn er kontinuierlich weiter gepflegt wird.
245€ ist jetzt auch nicht so weit weg vom Atmel bzw Microchip Programmer...

[Finger]

Die Produktpflege ist laufend gegeben. Updates kommen regelmäßig. Ich hatte auch schon Devices angefragt und die wurden binnen zwei Tagen integriert und ich bekam ein Beta zum testen. Ich mag die Firma

Moin,
danke für den Tipp.
Eigentlich würde ich ja davon ausgehen, dass ein Programmer des Herstellers, der mit der Firmware versorgt wurde, die den Problemchip explizit einschließt, funktioniert.

Der Forte hat ja auf dem Papier überzeugende Werte gegenüber dem Presto, ausleben kann er die aber natürlich nur, wenn er kontinuierlich weiter gepflegt wird.
245€ ist jetzt auch nicht so weit weg vom Atmel bzw Microchip Programmer...

[shaun]

Ich hab mir das Ding heute bestellt.
Gestern angefragt, heute Tracking-Link bekommen und seit 20 Uhr ist es auch schon in den Fängen DHLs.

Bin gespannt!

[Finger]

Schon ausprobiert?