-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Schlagwort: Arduino

TC1 Multifunction Tester: Open-Source Firmware flashen, kalibrieren und die Stolperfallen dabei

5. April 2026 / / Keine Kommentare
TC1 Multi-function Tester mit originaler M-Tester Firmware auf dem Display

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 Open-Source m-firmware von madires kann deutlich mehr: bessere Erkennung, Kalibrierung, zusätzliche Bauteile, IR-Decoder und ein sauberes Menü. 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?

PCB-Rueckseite des TC1 mit ATmega324PA Hauptprozessor und STC15L104W Power-Management-Chip

Auf der Rückseite der Platine sitzen zwei Chips, die man kennen muss:

Nahaufnahme des ATmega324PA-U-TH Chips auf der TC1-Platine

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.

Nahaufnahme des STC15L104W (U4) Power-Management-Chips im SOP-8 Gehaeuse

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.

Atten ST-862D Heissluft-Rework-Station zum Ausloeten des STC15L104W
Sugon T3602 Dual-Channel Loetstation mit Temperaturanzeige auf dem Arbeitsplatz

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.

FT232RL USB-TTL Adapter mit Jumper auf 3.3V fuer das STC15L104W Flashing

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

Ausgeloeteter STC15L104W auf Breadboard verkabelt mit FT232RL Adapter zum Flashen

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

Arduino Uno als ISP-Programmer mit Dupont-Kabeln an den Digital-Pins
Arduino Uno Power-Seite mit VCC und GND Verkabelung fuer ISP-Programmierung

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.

ISP-Kabel am J4-Header auf der TC1-Platinenrueckseite angeschlossen
Seitenansicht des TC1 mit angeschlossenem ISP-Kabel am J4-Header

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.

TC1 Display zeigt Bat 3.83V ok und Probing nach korrekter BAT_DIRECT Konfiguration

So soll das aussehen. 3.83V, alles ok.

Menü und Kalibrierung

TC1 Menue mit Adjustment-Option fuer die Kalibrierung nach Firmware-Flash

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

TC1 Startbildschirm zeigt Component Tester v1.56m nach erfolgreichem Flash

Component Tester v1.56m. Läuft.

TC1 mit m-firmware zeigt korrekt gemessenen 220 Ohm Widerstand an
TC1 erkennt MOSFET N-ch enh. mit Vth, Cgs und Rds Werten nach Firmware-Update

Widerstände, MOSFETs, alles wird sauber erkannt. Die Werte passen.

MOSFET-Messung auf dem TC1 nach Kalibrierung mit praezisen Vth und Rds Werten

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? Vermutlich nicht, die originale Firmware funktioniert ja auch. Aber die m-firmware ist einfach besser: genauere Messungen, mehr erkannte Bauteile, 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:

Siehe auch:

Fragen zum TC1 oder eigene Erfahrungen beim Flashen? Dann kannst du mich gerne fragen.

Arduino und die jammernde Pflanze: Technik trifft Humor

26. Februar 2022 / / Ein Kommentar

Auf irgendeinem CCC Event bin ich über eine lustige Projektidee einer jammernden Pflanze gestoßen. Die hat mir und auch meiner größeren Tochter so gut gefallen, dass wir sie zusammen nachbauen wollten.

Geöffnetes Gehäuse mit der gesamten Technik für das Arduino-Projekt: Die jammernde Pflanze

Die Idee

Ein kleines Gerät misst den Feuchtigkeitsgehalt der Blumenerde. Ist der Wert zu trocken, spielt ein MP3-Player eine Audiodatei ab. Ein Bewegungsmelder sorgt dafür, dass die Pflanze sich nur beschwert, wenn auch jemand da ist. Ist die Erde trocken und es wird eine Bewegung erkannt, jammert die Pflanze los.

Die Bauteile

Da es das erste Projekt dieser Art für meine Tochter ist, sollte es übersichtlich und einfach bleiben. Ein Arduino Nano (fast die gleichen Möglichkeiten wie der UNO, aber deutlich kleiner), ein DFPlayer-Modul als MP3-Player, ein HC-SR312 Bewegungsmelder und ein kapazitiver Feuchtigkeitssensor.

Aufbau und Entwicklung

Gestartet haben wir mit einem Breadboard, um die Verschaltung Modul für Modul zu setzen und die Ansteuerung mit dem Arduino anhand der Beispiele zu testen. Beim DFPlayer haben wir per TTS Texte in MP3s umgewandelt und auf der SD-Karte im Ordner mp3 gespeichert. Diese werden zufällig abgespielt, wenn die Erde zu trocken ist und eine Bewegung erkannt wurde.

Als die Verschaltung zusammen mit dem Code funktionierte, haben wir mit KiCad eine Platine designt und fertigen lassen. So hat man weniger Kabelsalat und alles ist platzsparend aufgehoben.

Elektrischer Schaltplan für die jammernde Pflanze

Das Gehäuse haben wir in FreeCAD designt und mit dem 3D-Drucker gedruckt. Die Teile sind mit einem Tropfen Sekundenkleber fixiert.

FreeCAD-Design des Gehäuses für die jammernde Pflanze

Im Einsatz

Das Teil steckt in der Blume und meldet sich zuverlässig, wenn es Zeit zum Gießen ist. Da es von den MP3s auf dem Player abhängt, was die Pflanze „sagt“, sind lustige Reaktionen garantiert. Die Pflanze kann dich im Vorbeigehen voll jammern, um Wasser betteln oder anfangen zu schimpfen.

Meine Tochter wird nach dem Projekt nicht alles alleine wiederholen können, aber die einzelnen Schritte sind klar. Wie so ein Gerät entsteht, was nötig ist. Schnell findet man Verbesserungsmöglichkeiten: Den Feuchtigkeitssensor von der Elektronik trennen, mit einem NodeMCU ESP8266 WLAN-Statusdaten senden, oder mit Li-Ion-Akkus und einem BMS vom Stromnetz unabhängig werden.

Quellcode

Für den DFPlayer wird die DFRobotDFPlayerMini Library benötigt (lokal unter ~/Arduino/libraries ablegen).

#include <Arduino.h>
#include <SoftwareSerial.h>
#include <DFRobotDFPlayerMini.h>

/* --- Pins ---------------------------------------------------- */
const uint8_t PIN_DF_RX   = 10;
const uint8_t PIN_DF_TX   = 11;
const uint8_t PIN_PIR     = 7;
const uint8_t PIN_SENSOR = A0;

/* --- Parameter ----------------------------------------------- */
const int schwellwert = 380;
const unsigned long PLAY_COOLDOWN_MS = 15000;
const uint8_t TRACK_JAMMERN = 1;

/* --- Objekte ------------------------------------------------- */
SoftwareSerial dfSerial(PIN_DF_RX, PIN_DF_TX);
DFRobotDFPlayerMini dfPlayer;

/* --- Laufzeitstatus ------------------------------------------ */
unsigned long lastPlay = 0;

/* ------------------------------------------------------------- */

void setup() {
  pinMode(PIN_PIR, INPUT);

  Serial.begin(115200);
  dfSerial.begin(9600);

  Serial.println(F("Initializing DFPlayer ..."));

  if (!dfPlayer.begin(dfSerial)) {
    Serial.println(F("DFPlayer init failed"));
    while (true);
  }

  dfPlayer.volume(20);
  dfPlayer.outputDevice(DFPLAYER_DEVICE_SD);
  dfPlayer.EQ(DFPLAYER_EQ_NORMAL);
  dfPlayer.setTimeOut(500);

  Serial.println(F("DFPlayer Mini online"));
}

/* ------------------------------------------------------------- */

void loop() {
  /* DFPlayer Events immer zuerst abholen */
  if (dfPlayer.available()) {
    handleDFPlayerEvent(dfPlayer.readType(), dfPlayer.read());
  }

  int messwert = analogRead(PIN_SENSOR);
  bool bewegung = digitalRead(PIN_PIR) == HIGH;
  bool trocken = messwert > schwellwert;

  unsigned long now = millis();

  if (trocken && bewegung) {
    if (now - lastPlay >= PLAY_COOLDOWN_MS) {
      Serial.println(F("Bewegung + Erde trocken -> spiele Sound"));
      dfPlayer.play(TRACK_JAMMERN);
      lastPlay = now;
    }
  } else {
    logStatus(trocken, bewegung, messwert);
  }

  delay(100);  // leichte Entlastung – kein Logik-Delay
}

/* ------------------------------------------------------------- */

void logStatus(bool trocken, bool bewegung, int messwert) {
  if (!bewegung && trocken) {
    Serial.print(F("Keine Bewegung, Erde trocken: "));
  } else if (bewegung && !trocken) {
    Serial.print(F("Bewegung, Erde ok: "));
  } else if (!bewegung && !trocken) {
    Serial.print(F("Keine Bewegung, Erde ok: "));
  }
  Serial.println(messwert);
}

/* ------------------------------------------------------------- */

void handleDFPlayerEvent(uint8_t type, int value) {
  if (type == DFPlayerPlayFinished) {
    Serial.print(F("Track "));
    Serial.print(value);
    Serial.println(F(" beendet"));
  }
}

Downloads

3D-Druck: STL Gehäuse | STL Deckel
Platine: Gerber-Dateien

Einkaufsliste

Optional: Breadboard mit Kabeln, Multimeter, Lötkolben

Fragen? Einfach melden.

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑