Es gibt diese kleinen Bauteiltester aus China, die für 15 bis 20 Euro auf AliExpress oder Amazon rumschwirren. Der TC1, auch bekannt als LCR-TC1. Transistoren, Widerstände, Kondensatoren, MOSFETs, Dioden. Bauteil in den ZIF-Sockel stecken, Knopf drücken, fertig. Für den Preis eigentlich erstaunlich brauchbar. Aber die originale Firmware ist halt, sagen wir mal, solide Mittelklasse. Die Messgenauigkeit geht in Ordnung, aber nicht mehr, und die Zahl der erkannten Bauteile ist überschaubar. In der Open-Source-Welt gibt es zwei Firmware-Varianten für diese Tester: Die k-firmware als stabiles Original und die m-firmware von madires als aktiv weiterentwickelter Rewrite. Präzisere Messungen, mehr erkannte Bauteile, bessere IR-Protokollunterstützung, flexiblere Konfiguration und ein sauberes Menü mit Kalibrierung. Also habe ich mich drangesetzt.
Was als „schnell mal neue Firmware drauf“ geplant war, wurde ein mehrtägiger Abstieg in die Untiefen von STC-Microcontrollern, falschen Pinouts und parasitärer Stromversorgung. Aber der Reihe nach.
Was steckt im TC1?
Auf der Rückseite der Platine sitzen zwei Chips, die man kennen muss:
U1: ATmega324PA — der Hauptprozessor. Ein Atmel AVR im TQFP-44 Gehäuse, 32 KB Flash, 2 KB SRAM, 1 KB EEPROM. Hier läuft die eigentliche Tester-Firmware. Wird über ISP (In-System Programming) geflasht, also braucht man einen Programmer.
U4: STC15L104W — ein winziger 8051-kompatibler Mikrocontroller im SOP-8 Gehäuse von STC Micro. Der macht das Power-Management: Einschalten per Tastendruck, automatisches Abschalten nach Timeout. Klingt trivial, ist aber der Chip, der mir die meisten Kopfschmerzen bereitet hat.
Beide Chips brauchen neue Firmware. Die m-firmware liefert die Hex-Dateien für beide: ComponentTester.hex für den ATmega und u4.hex für den STC. Klingt einfach. War es nicht.
Erster Versuch: Backup der Original-Firmware
Bevor man irgendwas überschreibt, will man natürlich ein Backup. Gute Idee, klappt nur nicht. Die Lock Bits des ATmega sind auf 0xC0 gesetzt. Das bedeutet: Lesen des Flash-Inhalts ist gesperrt. Man kann die Firmware löschen und neu schreiben, aber nicht auslesen. Kein Backup möglich. Also Augen zu und durch.
U4 flashen: Der schwierigste Teil
Der STC15L104W hat einen eingebauten UART-Bootloader. Klingt praktisch. Man braucht theoretisch nur einen USB-TTL Adapter, sendet das Hex-File und der Chip programmiert sich selbst. Theoretisch. In der Praxis muss der Chip für den Bootloader einen sauberen Power-Cycle bekommen, also Strom weg, Strom wieder an. Und genau hier fängt das Drama an.
Im eingelöteten Zustand liegt VCC des STC über den Button-Schaltkreis auf GND. Der Bootloader startet schlicht nicht. Der Chip muss raus.
Also Atten ST-862D Heißluftstation raus, SOP-8 Chip bei 280°C vorsichtig von der Platine gehoben, Pads sauber gemacht. Zum späteren Wiedereinlöten dann die Sugon T3602. Für solche SMD-Arbeiten will man vernünftiges Werkzeug, mit einem 15-Euro-Lötkolben aus dem Baumarkt wird das nichts.
Der CH341 und seine 5V-Lüge
Erster Versuch: CH341 USB-TTL Adapter. Steht „3.3V“ drauf, also sollte das passen. Der STC15L104W ist ein 3.3V-only Chip, 5V auf den Datenleitungen wären sein Todesurteil. Also Multimeter dran, TX-Pin messen und… 5V. Auf dem TX-Pin. Trotz „3.3V“-Stellung. Der CH341 hat zwar einen 3.3V Spannungsregler für VCC, aber die Logikpegel auf TX bleiben bei 5V. Das steht nirgendwo auf dem Board, nirgendwo im Datenblatt des Adapters. Man muss es wissen oder messen.
Hätte ich nicht nachgemessen, wäre der STC jetzt Elektroschrott. Lektion gelernt: Immer nachmessen, nie dem Aufdruck vertrauen.
Also einen FT232RL USB-TTL Adapter bestellt. Der hat einen echten 3.3V/5V Jumper, der tatsächlich auch die Logikpegel umschaltet. Nachgemessen: TX bei 3.3V. Endlich.
Das Pinout-Desaster
Jetzt wirds peinlich. Ich habe stundenlang versucht, den STC über Pin 1 (P3.4) und Pin 3 (P3.5) anzusprechen. Keine Reaktion. Kein Bootloader. Nichts. Irgendwann habe ich nochmal das Datenblatt studiert und festgestellt: P3.4 und P3.5 sind GPIO-Pins. Die UART-Pins (RXD/TXD) liegen auf P3.0 und P3.1, also Pin 5 und Pin 6. Das SOP-8 Pinout:
┌──────────┐
Pin 1 │● P3.4 │ Pin 8 (P3.3)
Pin 2 │ VCC │ Pin 7 (P3.2)
Pin 3 │ P3.5 │ Pin 6 ← TXD (P3.1)
Pin 4 │ GND │ Pin 5 ← RXD (P3.0)
└──────────┘
Stunden. Am falschen Pin. Das sind so Momente, in denen man kurz aufstehen und was trinken gehen sollte. Keine Ahnung, warum ich die falschen Pins unbedingt wollte… Ich hab auf das Datenblatt geschaut und… na, vielleicht war die Brille dreckig, keine Ahnung. „Leider“ kamen da auch sinlose Daten bei zustande, was erst nach einer falschen Baudrate ausgesehen hat; vielleicht ist das eine gute Ausrede, warum ich da so lange hängen geblieben bin?!
Parasitäre Stromversorgung und der Breadboard-Aufbau
Das nächste Problem: Der STC-Bootloader braucht einen Power-Cycle zum Starten. Also VCC abziehen, Flash-Tool starten, VCC wieder anlegen. Sollte klappen. Tat es aber nicht zuverlässig. Warum? Der Chip versorgt sich über die TX/RX-Datenleitungen parasitär mit Strom. Selbst wenn VCC getrennt ist, reicht der Strom über die Schutzdioden in den I/O-Pins, um den Chip am Leben zu halten. Kein sauberer Power-Cycle, kein Bootloader.
Die Lösung: Beim Power-Cycle ALLE Drähte trennen, nicht nur VCC. Erst das Flash-Tool starten (wartet auf den Chip), dann alle Leitungen gleichzeitig einstecken. Dazu ein 220 Ohm Serienwiderstand auf der TX-Leitung als Schutz und ein 100nF Stützkondensator zwischen VCC und GND für eine stabile Versorgung.
Geflasht habe ich unter Linux mit stcgal:
stcgal -P stc15 -p /dev/ttyUSB1 -l 2400 -b 4800 -t 12000 u4.hex
Der Trick ist die niedrige Baudrate (-l 2400 für die initiale Kommunikation, -b 4800 zum Flashen) und das erhöhte Timeout (-t 12000). Zur Verifikation habe ich das Ganze nochmal mit STC-ISP v6.96S unter Windows (VirtualBox) gegengeprüft. Beides erfolgreich. Chip wieder eingelötet, weiter gehts.
U1 flashen: Der einfache Teil
Der ATmega324PA wird über ISP programmiert. Als Programmer dient ein ganz normaler Arduino Uno mit dem ArduinoISP-Sketch. Den lädt man in der Arduino IDE über File → Examples → ArduinoISP auf den Uno. Dann die Pins verbinden: MOSI (D11), MISO (D12), SCK (D13), RESET (D10) vom Arduino an den J4-Header auf der TC1-Rückseite, plus VCC und GND.
Auf der TC1-Platine gibt es ein J4-Pad für ISP. Ich habe da einen Pin-Header aufgelötet, das macht das Leben bei zukünftigen Updates deutlich einfacher. Dann mit avrdude:
avrdude -c avrisp -p m324pa -P /dev/ttyACM0 -b 19200 -U flash:w:ComponentTester.hex:i
Das ging durch. Erster Versuch. Nach dem STC-Drama fühlte sich das fast verdächtig einfach an.
„Kas Rh- _BB“ — Was zur Hölle?
Nach dem Flashen das Display eingeschaltet und… „Kas Rh- _BB“ statt „Bat 3.83V ok“. Die Zeichen sahen aus wie ein kaputtes Font-Rendering. Stundenlang habe ich nach SPI-Fehlern gesucht, den Display-Treiber hinterfragt (ST7735 vs. SEMI_ST7735), die Pin-Belegung dreimal geprüft. Nichts half.
Die Lösung war so simpel wie ärgerlich: „Kas“ ist der Anfang von „Kaseikyo“, einem IR-Protokollnamen. Die m-firmware speichert Strings standardmäßig im EEPROM (DATA_EEPROM in der config.h). Aber ich hatte nur die .hex-Datei geflasht, nicht die .eep-Datei fürs EEPROM. Die Firmware las also zufällige alte Daten aus dem EEPROM und interpretierte sie als Text.
Der Fix: In der config.h DATA_FLASH statt DATA_EEPROM setzen. Dann werden alle Strings direkt im Flash-Speicher abgelegt und man braucht kein separates EEPROM-Flashing. Nochmal kompiliert, nochmal geflasht. Uff… Bis ich darauf gekommen bin *kopfschüttel*. Zugegeben, darüber nachgedacht habe ich aber ich war mir fast sicher das in einem mit geflashed zu haben. Fast sicher halt. Eine Nacht darüber schlafen hat geholfen, klassisch also im Problem festgefressen.
Batteriespannung: 19V aus einer LiPo-Zelle?
Nächstes Problem: Das Display zeigte 19V Batteriespannung an. Der TC1 läuft mit einer einzelnen LiPo-Zelle, das sind 3,7 bis 4,2V. Die Standard-Konfiguration der m-firmware geht von einem Spannungsteiler auf der Batterieleitung aus (BAT_DIVIDER mit R1=10k, R2=3.3k für einen 9V-Block). Der TC1 hat aber keinen Spannungsteiler, die Batteriespannung geht direkt an den ADC.
Fix: BAT_DIRECT statt BAT_DIVIDER in der config.h. Dazu die Schwellwerte anpassen: BAT_WEAK=3400 und BAT_LOW=3100 (in mV) für eine einzelne LiPo-Zelle.
So soll das aussehen. 3.83V, alles ok.
Menü und Kalibrierung
Noch ein Stolperstein: Das Menü war nicht erreichbar. Die m-firmware hat verschiedene Wege, das Menü aufzurufen. Beim TC1 funktioniert das über UI_SHORT_CIRCUIT_MENU: Alle drei Probe-Pins im ZIF-Sockel kurzschließen und Start drücken. Dann öffnet sich das Menü mit Optionen für PWM, IR-Detector, Opto Coupler, Test und eben Adjustment.
Die Kalibrierung selbst ist einfach: Adjustment auswählen, mit leerem ZIF-Sockel starten, dann wenn gefordert einen Kurzschluss zwischen 123 einstecken. Die Firmware misst die internen Referenzen und speichert die Korrekturdaten. Dann den Kurzschluss wieder raus und es wird die Gegenprobe gemessen.
Die vollständige Konfiguration
Für alle, die das selbst machen wollen, hier die kompletten Änderungen gegenüber der Standard-Konfiguration der m-firmware (ComponentTester v1.56m):
Makefile:
MCU = atmega324p FREQ = 16
config.h:
#define DATA_FLASH /* Strings im Flash statt EEPROM */ #define UI_AUTOHOLD /* Messergebnis halten bis Tastendruck */ #define UI_SHORT_CIRCUIT_MENU /* Menü über Kurzschluss aller Probes */ #define BAT_DIRECT /* Kein Spannungsteiler auf Batterie */ #define BAT_WEAK 3400 /* Warnung unter 3.4V */ #define BAT_LOW 3100 /* Abschaltung unter 3.1V */
config_644.h (Hardware-Mapping für den TC1):
/* Display: ST7735 über SPI Bit-Bang */ #define LCD_ST7735 #define LCD_RES PB4 #define LCD_DC PB5 #define LCD_SDA PB6 #define LCD_SCL PB7 #define LCD_FLIP_X #define LCD_ROTATE #define LCD_OFFSET_X 2 #define LCD_OFFSET_Y 1 #define LCD_LATE_ON #define SPI_BITBANG /* SDA auf PB6 statt Hardware-MOSI PB5 */ /* Probe-Widerstände auf PORTC statt PORTD */ /* PC0-PC5 für die drei Probe-Paare */ /* Power und Button */ #define POWER_PORT PORTD #define POWER_PIN PD2 #define BUTTON_PIN PD1 /* ADC-Pins vertauscht gegenüber Default */ #define TP_ZENER PA4 #define TP_REF PA3
Das Ergebnis
Component Tester v1.56m. Läuft.
Widerstände, MOSFETs, alles wird sauber erkannt. Die Werte passen.
Nach der Kalibrierung werden die Messwerte nochmal präziser. Vth 2065mV, Cgs 11.27nF, Rds 0.03 Ohm. Für einen 20-Euro-Tester absolut brauchbar.
Fazit und Quellen
War das ganze Prozedere nötig? Die originale Firmware funktioniert ja grundsätzlich. Aber wenn man sich auf die Messwerte verlassen will und nicht bei jedem unbekannten Bauteil rätseln möchte, lohnt sich der Aufwand. Die m-firmware liefert präzisere Ergebnisse, erkennt deutlich mehr Bauteile und hat ein richtiges Menü mit Kalibrierung. Und der J4-Header ist jetzt drauf, das nächste Firmware-Update ist dann tatsächlich in fünf Minuten erledigt.
Die fertige Firmware mit allen Config-Anpassungen für den TC1 und eine Schritt-für-Schritt-Anleitung habe ich auf GitHub gepackt. Da liegt auch die U4-Firmware (tc1-u4, GPL v3) und ein Verweis auf die m-firmware (EUPL v1.2).
Wer sich tiefer einlesen will:
- Flashing-Anleitung von wohali — der Gist, der mich überhaupt auf die Idee gebracht hat
- EEVBlog TC1 Thread — hunderte Seiten Community-Wissen zum TC1
- AVR Transistortester auf mikrocontroller.net — der deutschsprachige Standardartikel
- STC15F104 Wiki — Pinout und Grundlagen zum STC-Chip
Siehe auch:, Multifunktionstester für Elektronikbauteile: Schnell & günstig prüfen
- OWON XDM1041: Firmware V4.7.0 (20220913) – Update-Dateien und Vorgehen
- Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt
- Voltcraft CM 2016: Endlich eine Linux-GUI für das Ladegerät
- FNIRSI GC-01 Upgrade: Akku, Zählrohr & Rad Pro Firmware installieren
Fragen zum TC1 oder eigene Erfahrungen beim Flashen? Dann kannst du mich gerne fragen.
Pahhh da boote ich ganz cool meine Linux-Schüssel, hänge die USB-Platte ein und passe meine exports für einen ganz einfachen und schnellen Share an: