Blue Pills mit gefälschtem STM32? VBatt funktionslos!

Eigentlich funktionierte mein RFID-Reader Projekt einwandfrei - auf dem Breadboard.

Als alles fertig entwickelt und getestet war, entwarf ich ein Gehäuse für den RFID-Reader, druckte es mit meinem 3D-Drucker, einem Anycubic i3 mega, und baute die Einzelteile ein.

Dafür verwendete ich natürlich eine andere Blue Pill, da die Header jetzt nicht nach unten (für das Breadboard), sondern nach oben (für das Gehäuse) zeigen sollte. Später fiel mir dann auf, dass der RFID-Reader immer die Zeit vergaß. Dabei hatte ich doch extra zwei große AA Batterien mit in das Gehäuse gepackt.

Ich war erstmal froh, dass der RFID-Reader in der Hauptsache das tat, was er sollte und hatte keine Lust bzw. gerade wichtigere Projekte, nach dem Fehler zu fahnden. Ich checkte natürlich, ob das VBatt-Kabel evtl. zu lose eingesteckt war, ob die Batterie nicht evtl. schon leer usw., aber auf die Schnelle ließ sich nichts finden.

Doch heute wollte ich der Sache auf den Grund gehen, nachdem sich auch ein anderes Blue Pill Board bezüglich der Zeit vergesslich zeigte.

Die Testsoftware

Also ging ich meine Boards durch und testete mit einem kleinen Programm, ob sie die Zeit behalten würden oder nicht, sprich: ob die Batterie-Pufferung über VBatt funktionierte oder nicht. Das liest die Zeit aus der RTC und schaut, ob diese gültig ist. Ist die Zeit gültig, blinkt die LED auf dem Board im Halbsekundentakt. Ist keine gültige Zeit vorhanden - hat also die Batteriepufferung versagt - blinkt sie schnell; gleichzeitig wird die Zeit gesetzt. Spätestens beim zweiten mal einschalten sollte die Schaltung also langsam blinken, sonst wäre VBatt ohne Funktion.

Nach einem Reset sollte die LED auch langsam blinken, denn der Strom war ja nicht getrennt, die Zeit inzwischen aber gesetzt. Der Source zu dem kleinen Testprogramm sieht so aus (die Headerfiles findet ihr übrigens in einem älterem Projekt von mir hier):

RTC-Test.cpp (klicken, um diesen Abschnitt aufzuklappen)

////////////////////////////////////////////////////////
// (C) 2020 by Oliver Kuhlemann                       //
// Bei Verwendung freue ich mich über Namensnennung,  //
// Quellenangabe und Verlinkung                       //
// Quelle: http://cool-web.de/arduino/                //
////////////////////////////////////////////////////////

// uses https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/RTClock


#include <RTClock.h>
#include "DateTime.h"
#include "RTCInterface.h"

// den genauen 32768 Hertz-Timer für die Uhr benutzen (LSE),
// auch ist nur der LSE durch VBat abgesichert
RTClock rtclock (RTCSEL_LSE); 

int blinkDur=10; // 500ms = RTC-Zeit war gebuffert, 100ms = RTC-Zeit war (noch) nicht gebuffert (evtl. aus/an, weil beim ersten mal die Zeit geschrieben wird)


void setup() {
  char buf[25];

  //Serial.begin(115200);

  pinMode(PC13, OUTPUT);
  
  delay(1000); // auf die ser. Schnittstelle warten

  Serial.println (F("Compile-DateTime:"));

  Serial.println (__DATE__);
  Serial.println (__TIME__);

  DateTime compdat;
  DateTime rtcdat;

  compdat = getCompileDateTime();

  storeDateTimeInString (compdat, buf, false); // Compile-Datum ausgeben
  Serial.println (buf);

  storeDateTimeInString (compdat, buf, true); // Compile-Datum mit Wochentag
  Serial.println (buf);

  uint64_t ts64;
  ts64=getDateTimeAsUint64(compdat); // Compile-Datum und Zeit als Zahl
  Serial.println (ts64);

  uint32_t ts32;
  ts32=getDateAsUint32(compdat); // Compile-Datum als Zahl
  Serial.println (ts32);

  ts32=getTimeAsUint32(compdat); // Compile-Zeit als Zahl
  Serial.println (ts32);

  Serial.println (F("\nRTC-DateTime:"));
  rtcdat = getRtcDateTime(rtclock);

  storeDateTimeInString (rtcdat, buf, true); // RTC-Datum ausgeben
  Serial.println (buf);


  if ( getDateAsUint32(rtcdat) < getDateAsUint32(compdat)) { // RTC-Zeit aus der Vergangenheit, kann nicht stimmen
    // Kopilierungszeit in Echtzeituhr speichern
    setRtcDateTime (rtclock, compdat);
    Serial.println (F("RTC-Uhrzeit auf Kompilierungszeit gesetzt."));
    // ansonsten mit der Zeit in der RTC weitermachen
    blinkDur=100;
  } else {
    blinkDur=500;
  }

}

void loop() {
  DateTime rtcdat;
  char buf[25];
  
  time_t tt;  // Sekunden seit 01.01.1970
  // tm_t mtt;   // struct (year (+1970), month, day, weekday, weekday, pm, hour, minute, second

  if ( Serial.available() > 14 ) {  // 20190515-091017 // setzen der Uhrzeit per Ser-Schnittstelle

    DateTime serdat;
    for (byte i = 0; i < 15; i++) {
      buf[i] = Serial.read();
    }
    Serial.flush();
    buf [15] =0;
    sscanf (buf, "%4d%2d%2d-%2d%2d%2d", &serdat.year, &serdat.month, &serdat.day, &serdat.hour, &serdat.minute, &serdat.second);
    setRtcDateTime (rtclock, serdat);

  }

  tt = rtclock.getTime();
  Serial.println(tt);
    
  rtcdat = getRtcDateTime(rtclock);

  storeDateTimeInString (rtcdat, buf, true); // RTC-Datum mit Wochentag
  Serial.println (buf);

  delay (blinkDur);
  digitalWrite (PC13, !digitalRead(PC13));
}

STM32 F103C8T6 CHN - Fake oder nur teildefekt?

Mit diesem Progrämmchen habe ich dann all meine Blue Pills durchgetestet. Und es hat sich dabei herausgestellt, dass die Blue Pills mit einem "CHN nnn" in der letzten Zeile alle nicht richtig funktionieren.

Ich dachte ja erst, da wäre ein Widerstand bei der Bestückung verwechselt worden oder dergleichen. Aber nein, die Komponenten auf den funktionierenden und den fehlerhaften Boards ist genau die gleiche.

Auch hätte ich mir gut vorstellen können, dass die Chips, in deren ersten Zeile "STM32F" statt "STM32" steht, die Bösewichter wären. Doch nichts da, die "STM32F"'s funktionierten (zumindestens in Hinsicht auf VBatt) einwandfrei.

Meine Tests habe ich in einem Video zusammengeschnitten:

Klicken Sie auf diesen Button, um das Vorschaufenster (sogenanter IFrame) für ein Youtube-Video anzuzeigen. Beachten Sie, dass dann (bisher noch nicht) eventuell (wenn nicht durch Adblocker oder ähnliches verhindert) Cookies von Youtube, Google und damit verbundenen Drittfirmen gesetzt werden, die ihr Gerät über weitere IFrames dieser Art nachverfolgen können und speichern, welche Videos mit Ihrem Gerät angeschaut wurden.

Ich hatte mal einen 5er-Pack Blue Pills bei einem chinesischen Händler bestellt, den ich eigentlich als zuverlässig kenne. Ich schätze, die 5 STM32 CHN-Chips stammen aus dieser Bestellung. Ich glaube nicht, dass der Händler mit Vorsatz gehandelt hat. Wahrscheinlich nicht einmal der Platinenbestücker. Gut möglich, dass man ihm eine Ladung gefälschter Chips untergejubelt hat.

Die Beschriftung auf den Chipfälschungen sieht einwandfrei aus und ist in hoher Qualität gelasert. Aus das ST-Logo sieht täuschend echt aus. Von der Beschriftung der könnte ich die Fälschung nicht erkennen.

Was ich mir gut vorstellen kann, ist, dass ein chinesischer Halbleiterhersteller den STM32 "nachgebaut" hat und dabei ein paar Cents gespart hat, indem ein paar aufwendigere, aber wenig benutzte Schlatungen im IC weggelassen hat, wie eben z. B. die VBAT-Unterstützung. Und diese jetzt massenhaft auf den Markt wirft. Wer so professionell lasert, der schmirgelt sicher keine Chips im Hinterhof ab, um sie neu zu beschriften. Das ist schon ein größerer Coup.

Das wird STMicroelectronics, dem europäischen Unternehmen mit Sitz in Genf / Schweiz und Entwickler des STM32, sicher nicht gefallen, wenn da jemand en masse ihre Chips nachmacht.

Auch woanders sind Fälschungen aufgetaucht

Wenn die Fälschung des STM32F103-Chip wirklich groß angelegt ist, dann müsste dass doch auch anderen aufgefallen sein. Schauen wir einmal, was das Internet so dazu zu berichten hat.

Stefan Frings schreibt auf seiner Seite:

Leider sind Anfang 2020 vermehrt Module mit gefälschten Chips in Umlauf gekommen, die nicht korrekt funktionieren.

und verweist auf Richi´s Labs Seite STM32 - Originale und Fälschungen.
Richi hat hier ein paar Fotos von originalen und gefälschten STM32 F103 Chips veröffentlicht, wobei seine Fälschungen mit "MYS ..." und nicht wie bei mir mit "CHN ..." in der letzten Zeile gelabelt sind. Außerdem ist die Laserung bei seinen Chips nicht so professionell bei bei meinen CHN-Chips. Und meine MYSs funktionierten ja.

Hochinteressant sind die Bilder vom Inneren des Chips, die wohl abgeschliffen oder abgeätzt wurden. Hier zeigt sich sehr schnell, was eine Fälschung ist, gibt es doch Echtheitsmerkmale auf dem Die selbst.

Richis Sammlung enthält auch einen "CHN ..."-Chip, der sich bei ihm allerdings als Original herausgestellt hat. Dann hat Richi noch umgelabelte CKS32-Chips im Angebot. Aber auch hier ist das Label nicht so profesionell gelasert.

Bei diesem STM32 handelt es sich folglich um eine andere Art der Fälschung. Der CKS32 stellt einen bekannten und grundsätzlich funktionsfähigen STM32-Clon dar, die Beschriftung des Packages ist aber irreführend. Für einen Händler ist es sicherlich rentabel CKS32-Teile als STM32-Teile zu verkaufen.

Wenn ich auch mein STM32-CHN-Fake nicht in der Sammlung finde, so zeigt sich doch, dass das Problem mit STM32-Fakes nicht neu ist.

Auf der Foren-Seite mikrocontroller.net ist die Diskussion um STM32-Fake unter Experten und Hobbyisten in vollem Gange. Gestartet Anfang 2020 wird in diesem Thread fleißig gepostet - mitunter interessante Erkenntisse.

Keir Fraser hat auf seiner Github-Seite Greaseweazle ebenfalls Fotos und Erklärungen zu STM32-Fakes veröffentlicht. Als Funktionseinschärnkungen der Fakes nennt er:

- Cannot program at 921600 baud. Success at 115200 baud.
- Cannot start firmware from System Bootloader (Bootloader may not set the Reset SP?)
- Debug registers return valid non-zero info (contravenes Erratum 2.3 of genuine parts)
- Writing to backup registers, and then turning off the backup interface clock, seems to lock up parts of the chip: Future writes to certain registers hang forever with no exception or reset
- I2C peripheral won't allow CR1_ACK to be set in the same write that sets CR1_PE
- DMA peripheral generates spurious extra completion interrupts and is generally prone to lockup

Blaatshaap hat in seinem Blog STM32F103 Chips näher mit seinem JTAG-Debugger anhand ihrer JTAG Identification untersucht und kann so die unterschiedlichen Chips anhand derer Herstellerangaben einordnen.

Ich kann mit meinem STLink V2 zwar STM32s generell debuggen, aber an diese JTAG-Informationen komme ich damit nicht heran. Aber wer z. B. einen SEGGER J-Link wie BlaatShaap besitzt, der kann diese Infos herauskitzeln und ein wenig ins Innere des Chips schauen, ohne ihn gleich mikrometerweise abzuschleifen.

Die Meldungen, die er von OpenOCD zurückerhält haben das Muster

Info : JTAG tap: auto0.tap tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: auto1.tap tap/device found: 0x16410041 (mfg: 0x020 (STMicroelectronics), part: 0x6410, ver: 0x1)

Interessant sind hier die beiden 4-Byte Tags, die sich nach den Chips richten:

STM32F103C8T6 (STMicroelectronics)
  0x3ba00477   mfg: 0x23b (ARM Ltd.)
  0x16410041   mfg: 0x020 (STMicroelectronics)
  
GD32F101CBT6 (GigaDevice)
  0x4ba00477  mfg: 0x23b (ARM Ltd.)
  0x790007a3  mfg: 0x3d1 (GigaDevice Semiconductor (Beijing))
  
APM32F103C8T6 (ApexMic)
  0x4ba00477   mfg: 0x23b (ARM Ltd.)
  0x16410001   mfg: 0x000 (invalid)
  
BLM32F103C8T6
  0x4ba00477   mfg: 0x23b (ARM Ltd.)
  
CS32F103C8T6 (CKS)
  0x4ba00477   mfg: 0x23b (ARM Ltd.)
  0x16410041   mfg: 0x020 (STMicroelectronics)

MM32F103C8T6 (MindMotion)
  0x4ba00477   mfg: 0x23b (ARM Ltd.)