{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidg3mp5nzetswuwmct4vash66vmelixvd5ffz2mcrtvh2i57573zy",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmgexb4qvso2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiawebc32erksuq6jpwp43634qxvrtpheoeay4lqab6yzsgdbuyt5i"
    },
    "mimeType": "image/jpeg",
    "size": 131273
  },
  "description": "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. […]",
  "path": "/2026/04/05/tc1-multifunction-tester-open-source-firmware-flashen-kalibrieren/",
  "publishedAt": "2026-05-22T07:10:32.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "Arduino",
    "DIY",
    "Firmware",
    "löten",
    "OpenSource",
    "TC1",
    "m-firmware",
    "Atten ST-862D",
    "Sugon T3602",
    "FT232RL USB-TTL Adapter",
    "Datenblatt",
    "220 Ohm Serienwiderstand",
    "100nF Stützkondensator",
    "stcgal",
    "GitHub",
    "tc1-u4",
    "Flashing-Anleitung von wohali",
    "EEVBlog TC1 Thread",
    "AVR Transistortester auf mikrocontroller.net",
    "STC15F104 Wiki",
    "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"
  ],
  "textContent": "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.\n\nWas 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.\n\n### Was steckt im TC1?\n\nAuf der Rückseite der Platine sitzen zwei Chips, die man kennen muss:\n\n**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.\n\n**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.\n\nBeide 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.\n\n### Erster Versuch: Backup der Original-Firmware\n\nBevor 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.\n\n### U4 flashen: Der schwierigste Teil\n\nDer 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.\n\nIm eingelöteten Zustand liegt VCC des STC über den Button-Schaltkreis auf GND. Der Bootloader startet schlicht nicht. Der Chip muss raus.\n\nAlso 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.\n\n### Der CH341 und seine 5V-Lüge\n\nErster 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.\n\nHätte ich nicht nachgemessen, wäre der STC jetzt Elektroschrott. Lektion gelernt: Immer nachmessen, nie dem Aufdruck vertrauen.\n\nAlso 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.\n\n### Das Pinout-Desaster\n\nJetzt 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:\n\n\n            ┌──────────┐\n    Pin 1  │● P3.4    │  Pin 8  (P3.3)\n    Pin 2  │  VCC     │  Pin 7  (P3.2)\n    Pin 3  │  P3.5    │  Pin 6  ← TXD (P3.1)\n    Pin 4  │  GND     │  Pin 5  ← RXD (P3.0)\n           └──────────┘\n\nStunden. 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?!\n\n### Parasitäre Stromversorgung und der Breadboard-Aufbau\n\nDas 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.\n\nDie 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.\n\nGeflasht habe ich unter Linux mit stcgal:\n\n\n    stcgal -P stc15 -p /dev/ttyUSB1 -l 2400 -b 4800 -t 12000 u4.hex\n\nDer 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.\n\n### U1 flashen: Der einfache Teil\n\nDer 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.\n\nAuf 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:\n\n\n    avrdude -c avrisp -p m324pa -P /dev/ttyACM0 -b 19200 -U flash:w:ComponentTester.hex:i\n\nDas ging durch. Erster Versuch. Nach dem STC-Drama fühlte sich das fast verdächtig einfach an.\n\n### „Kas Rh- _BB“ — Was zur Hölle?\n\nNach 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.\n\nDie 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.\n\nDer 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.\n\n### Batteriespannung: 19V aus einer LiPo-Zelle?\n\nNä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.\n\nFix: `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.\n\nSo soll das aussehen. 3.83V, alles ok.\n\n### Menü und Kalibrierung\n\nNoch 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.\n\nDie 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.\n\n### Die vollständige Konfiguration\n\nFür alle, die das selbst machen wollen, hier die kompletten Änderungen gegenüber der Standard-Konfiguration der m-firmware (ComponentTester v1.56m):\n\n**Makefile:**\n\n\n    MCU = atmega324p\n    FREQ = 16\n\n**config.h:**\n\n\n    #define DATA_FLASH              /* Strings im Flash statt EEPROM */\n    #define UI_AUTOHOLD             /* Messergebnis halten bis Tastendruck */\n    #define UI_SHORT_CIRCUIT_MENU   /* Menü über Kurzschluss aller Probes */\n    #define BAT_DIRECT              /* Kein Spannungsteiler auf Batterie */\n    #define BAT_WEAK    3400        /* Warnung unter 3.4V */\n    #define BAT_LOW     3100        /* Abschaltung unter 3.1V */\n\n**config_644.h** (Hardware-Mapping für den TC1):\n\n\n    /* Display: ST7735 über SPI Bit-Bang */\n    #define LCD_ST7735\n    #define LCD_RES     PB4\n    #define LCD_DC      PB5\n    #define LCD_SDA     PB6\n    #define LCD_SCL     PB7\n    #define LCD_FLIP_X\n    #define LCD_ROTATE\n    #define LCD_OFFSET_X    2\n    #define LCD_OFFSET_Y    1\n    #define LCD_LATE_ON\n    #define SPI_BITBANG         /* SDA auf PB6 statt Hardware-MOSI PB5 */\n\n    /* Probe-Widerstände auf PORTC statt PORTD */\n    /* PC0-PC5 für die drei Probe-Paare */\n\n    /* Power und Button */\n    #define POWER_PORT  PORTD\n    #define POWER_PIN   PD2\n    #define BUTTON_PIN  PD1\n\n    /* ADC-Pins vertauscht gegenüber Default */\n    #define TP_ZENER    PA4\n    #define TP_REF      PA3\n\n### Das Ergebnis\n\nComponent Tester v1.56m. Läuft.\n\nWiderstände, MOSFETs, alles wird sauber erkannt. Die Werte passen.\n\nNach 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.\n\n### Fazit und Quellen\n\nWar 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.\n\nDie 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).\n\nWer sich tiefer einlesen will:\n\n  * Flashing-Anleitung von wohali — der Gist, der mich überhaupt auf die Idee gebracht hat\n  * EEVBlog TC1 Thread — hunderte Seiten Community-Wissen zum TC1\n  * AVR Transistortester auf mikrocontroller.net — der deutschsprachige Standardartikel\n  * STC15F104 Wiki — Pinout und Grundlagen zum STC-Chip\n\n\n\nSiehe auch:\n\n  * OWON XDM1041: Firmware V4.7.0 (20220913) – Update-Dateien und Vorgehen\n  * Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt\n  * Voltcraft CM 2016: Endlich eine Linux-GUI für das Ladegerät\n  * FNIRSI GC-01 Upgrade: Akku, Zählrohr & Rad Pro Firmware installieren\n\n\n\nFragen zum TC1 oder eigene Erfahrungen beim Flashen? Dann kannst du mich gerne fragen.",
  "title": "TC1 Multifunction Tester: Open-Source Firmware flashen, kalibrieren und die Stolperfallen dabei"
}