Forum: Mikrocontroller und Digitale Elektronik LF-1600 defekt


von Sebastian W. (wangnick)


Angehängte Dateien:

Lesenswert?

Liebe Leute,

meine XYTronic LF-1600 Lötstation ist defekt. Ich würde gerne zunächst 
versuchen sie zu reparieren.

Das Fehlerbild ist wie folgt: Die Anzeige bleibt dunkel und der 
Keramikheizer erhitzt sich langsam auf ~110°C.

Meine Version ist die mit THT-Komponenten und gesockeltem Atmega88PA-PU 
mit Stempel HS-K67121, wie sie Michael Büsch in 
Beitrag "Xytronic LF-1600 Reverse-Engineering" untersucht hat, sein 
Schaltplan hier: 
https://github.com/mbuesch/xytronic-lf/blob/3e740d81da22b26c7b77fa84eabfcf5f87d49b3c/schematics-lf1600/lf1600.pdf.

Bisher habe ich folgendes überprüft. Die Sicherung ist heile. Der Trafo 
liefert die benötigten 8V und 30V. Am Testpunkt B liegen wie erwartet 
+5V, am Testpunkt C wie erwartet -5V an.

Am Atmega88 liegen VCC, NRESET und GND sauber an. AVCC liegt bei ca. 
4.4V, AREF bei knapp unter 2.5V.

Anbei das Verhalten an den wichtigsten Ein- und Ausgängen des uC, einmal 
im Überblick über 10 Sekunden Einschaltdauer, und zum anderen ein Zoom 
auf die ersten 300ms nach dem Einschalten.

Ich kann mir nicht so recht erklären was hier passiert. Löst das 
Anschalten der Heizung eventuell einen Reset des Prozessors aus? 
Irgendwelche Ideen zum weiteren Vorgehen?

LG, Sebastian

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Sebastian W. schrieb:
> AVCC liegt bei ca.
> 4.4V

Das ist schon mal verdächtig. Sollte im Normalfall auch 5V sein wie VCC.

: Bearbeitet durch User
von KFZ (Gast)


Lesenswert?

Prüf mal C7. Testweise einfach auslöten und sehen ob AVCC nun 5V ist.

von Sebastian W. (wangnick)


Angehängte Dateien:

Lesenswert?

Matthias S. schrieb:
> Sebastian W. schrieb:
>> AVCC liegt bei ca.
>> 4.4V
>
> Das ist schon mal verdächtig. Sollte im Normalfall auch 5V sein wie VCC.

KFZ schrieb:
> Prüf mal C7. Testweise einfach auslöten und sehen ob AVCC nun 5V
> ist.

Fand ich auch seltsam. Aber ist bei der Schaltung zu erwarten: R12 und 
R11 teilen die Spannung zwischen VCC und AREF auf 4.4V. Und ich hab im 
Datenblatt noch einmal nachgelesen: Der Brownout-Detektor basiert auf 
VCC, nicht AVCC. Prüfung C7 ist dennoch notiert.

LG, Sebastian

: Bearbeitet durch User
von Michael B. (mb_)


Angehängte Dateien:

Lesenswert?

Komisch finde ich vor allem, dass die Anzeige tot ist.

Ich könnte mir vorstellen, dass der Microcontroller einen Schaden hat, 
oder ein Bit im Programm oder eeprom gekippt ist.
Hast du eine Möglichkeit einen AtMega88 zu flashen?
Ich würde mal einen neuen Controller einbauen. Ist ja durch den Sockel 
einfach machbar.

Im Anhang ist die Originalfirmware für den LF-1600 THT-Version.
Fuses sind in program.sh.

von Michael B. (mb_)


Angehängte Dateien:

Lesenswert?

Der Vollständigkeit halber hier auch noch die Firmware für die 
SMD-Version.

lfuse=0x62
hfuse=0xdf
efuse=0xf9

von Sebastian W. (wangnick)


Lesenswert?

Michael B. schrieb:
> Ich könnte mir vorstellen, dass der Microcontroller einen Schaden hat,
> oder ein Bit im Programm oder eeprom gekippt ist.
> Hast du eine Möglichkeit einen AtMega88 zu flashen?
> Ich würde mal einen neuen Controller einbauen. Ist ja durch den Sockel
> einfach machbar.

Hallo Michael,

leider habe ich keinen Atmega88XX-PU zur Hand, nur einen Atmega48-PU und 
einen Atmega328P-PU.

Ich habe also meinen Atmega328P-PU mit 
xytronic-lf-1.5\hex\board_legacy\atmega328p\release\fuses.txt, 
xytronic-lf.hex und xytronic-lf.eep.hex geflasht, und die Station 
funktioniert wieder!

Toll was du da programmiert hast!

Der original Atmega88PA-PU reagiert auf ISP-Programmierung nicht mehr. 
Ich könnte noch HVPP probieren (ich habe einen AVR Dragon), weil mich 
schon interessieren würde was dem armen Kerl passiert ist.

LG, Sebastian

von Michael B. (mb_)


Lesenswert?

Sebastian W. schrieb:
> Toll was du da programmiert hast!

Freut mich. Funktioniert bei mir auch seit Jahren einwandfrei.
Und das ist ja eigentlich ein Wunder, bei dieser Hardware.

Gerade bei der THT-Version bin ich der Meinung, dass der Microcontroller 
vor allem vom Display stark elektrisch gestresst wird. In der 
SMD-Version sind da Transistoren zur Ansteuerung der LEDs eingebaut.

> Ich könnte noch HVPP probieren (ich habe einen AVR Dragon), weil mich
> schon interessieren würde was dem armen Kerl passiert ist.

Ja, würde mich auch mal interessieren, ob der sich noch auslesen lässt.
Lock-Bits sind ja keine gesetzt vom Hersteller aus.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Michael B. schrieb:
> Gerade bei der THT-Version bin ich der Meinung, dass der Microcontroller
> vor allem vom Display stark elektrisch gestresst wird.

Ich hatte zugunsten des Herstellers angenommen, das die Vorwiderstände 
direkt an den Anzeigen sind. Aber wenn ich dich richtig verstehe, gibts 
gar keine?

: Bearbeitet durch User
von Michael B. (mb_)


Lesenswert?

Matthias S. schrieb:
> Ich hatte zugunsten des Herstellers angenommen, das die Vorwiderstände
> direkt an den Anzeigen sind. Aber wenn ich dich richtig verstehe, gibts
> gar keine?

Doch, Vorwiderstände sind da. Aber der AtMega treibt alle LEDs direkt, 
über diese Vorwiderstände.
Das ist wahrscheinlich alles noch innerhalb der Spezifikation, weil es 
ja gemultiplext wird und nie alle LEDs aktiv sind.
Man sieht aber mit bloßem Auge bereits enorme Helligkeitsunterschiede, 
je nachdem welche Zahlen angezeigt werden, also welche LED-Kombinationen 
aktiv sind.
Deshalb nehme ich an, dass das alles auf Kante genäht ist.

In der SMD-Version steuert der AtMega nur die Transistoren an, die dann 
die LEDs treiben. Das ist für mich der Hinweis, dass der Hersteller hier 
ein Problem erkannt hat.

Generell ist die Hardware ziemlich schlecht designed. In der SMD-Version 
fließt der Strom für den Kolben durch die zwei GND-Pins eines 
Mikrotasters hindurch. Da hat jemand wohl die Ausgabe des Autorouters 
nicht weiter hinterfragt. :)

Die Messschaltung für den Strom ergibt IMO auch vorne und hinten keinen 
Sinn. Und sie funktioniert auch praktisch nur für eine 
Ein-Aus-Erkennung. Ich denke das ist, was die originale Firmware macht. 
Habe das aber nie genauer untersucht.

Und sonst gibt es noch mehr etliche merkwürdige Dinge.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Michael B. schrieb:
> Die Messschaltung für den Strom ergibt IMO auch vorne und hinten keinen
> Sinn.

Das hat mich auch gewundert. Wozu misst man den Strom, den der Kolben 
aufnimmt? Unsinn. Um zu erkennen, das ein Kolben defekt ist, reichts ja, 
ihn ein wenig zu heizen und dann die Temperatur zu checken. Schön 
jedenfalls, das du das Dings entschlüsselt hast.

von Michael B. (mb_)


Lesenswert?

Matthias S. schrieb:
> Das hat mich auch gewundert. Wozu misst man den Strom, den der Kolben
> aufnimmt? Unsinn.

Ja. Weitgehend.
Ich vermute, dass es eine reine Kolben-ist-angesteckt-Erkennung in der 
Originalfirmware ist.

In meiner Firmware nutze ich das für eine Stromregelung. Funktioniert 
natürlich kaum, weil die Messschaltung so räudig ist.
Notwendig wäre eine Regelung hier selbstverständlich nicht.

von Sebastian W. (wangnick)


Lesenswert?

Michael B. schrieb:
>> Ich könnte noch HVPP probieren (ich habe einen AVR Dragon), weil mich
>> schon interessieren würde was dem armen Kerl passiert ist.
>
> Ja, würde mich auch mal interessieren, ob der sich noch auslesen lässt.
> Lock-Bits sind ja keine gesetzt vom Hersteller aus.

Ok, HVPP funktioniert. Der Inhalt des Flash entspricht haargenau deinem 
lf1600-flash.bin.hex, und der Eeprom-Inhalt ist auch identisch ausser 
dass an 0x10/0x11 0x96/0x00 anstelle von 0x4a/0x01 steht.

Die Fuses allerdings sind Low 0x62, High 0x0C, Extended 0xF9. Also kein 
Bootloader, Reset Disabled (!), DebugWire Enabled (!), SPI Enabled, WDT 
On (!), kein EE Save, BODLEVEL 4.3V (!), CKDIV8, kein CKOUT, und 
interner 8NHz RC Oszillator mit 6 CK/14CK + 65ms.

Laut deinem program.sh sollte die High-Fuse 0xDF sein. Es sind also 5 
Bits auf 0 gekippt. Mmh.

Das erklärt aber auch das von mir beobachtete Verhalten. Beim 
Einschalten wird 65ms auf den Oszillator gewartet, dann startet das 
Programm, und nach weiteren 16ms schlägt der Watchdog unerwartet zu und 
das Spielchen beginnt von vorn.

Michael B. schrieb:
> Gerade bei der THT-Version bin ich der Meinung, dass der Microcontroller
> vor allem vom Display stark elektrisch gestresst wird. In der
> SMD-Version sind da Transistoren zur Ansteuerung der LEDs eingebaut.

Am besten sollte ich wohl auch noch Transistoren in die 
Anodenzuleitungen einschleifen ...

LG, Sebastian

: Bearbeitet durch User
von Michael B. (mb_)


Lesenswert?

Sebastian W. schrieb:
> Das erklärt aber auch das von mir beobachtete Verhalten. Beim
> Einschalten wird 65ms auf den Oszillator gewartet, dann startet das
> Programm, und nach weiteren 16ms schlägt der Watchdog unerwartet zu und
> das Spielchen beginnt von vorn.

Whoa. Sehr interessant. Da sind tatsächlich die Fuses gekippt.
Hätte ich nicht gedacht.

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
Noch kein Account? Hier anmelden.