Support VCDS V2 Supportthread: Fragen, Infos und HowTo

Malisums schrieb:

Kurzes Update: Hardwareanalyse abgeschlossen – STM32F429 Testboards sind angekommen

Hallo zusammen,

mal wieder ein Update zum aktuellen Stand meines Projekts.

Zuerst noch einmal vielen Dank an alle, die mir bisher Informationen, Loader, Dumps oder andere Vergleichsdaten geschickt haben. Das hat mir bei der Analyse wirklich sehr geholfen.

Der umgebaute Dongle ist inzwischen wieder bei mir und ich konnte die herausgeführten Pins direkt am STM32 testen.

Dadurch war es jetzt endlich möglich, den Debug-Zugriff sauber und ohne irgendwelche Vermutungen direkt am Controller zu prüfen.

Verwendet habe ich unter anderem einen ST-Link V2 und OpenOCD.

Die Target-Spannung liegt stabil bei ca. 3,27–3,28 V. Der STM32 läuft normal und auch der Dongle selbst meldet sich weiterhin sauber über USB als:

Spoiler

Code:

VID: 0483
PID: A0CB

Ross-Tech HEX-V2

Der Dongle ist also elektrisch definitiv nicht tot.

USB funktioniert, der Controller läuft und auch die Kommunikation mit dem Loader findet weiterhin statt.

Der direkte Debug-Zugriff sieht allerdings ziemlich eindeutig aus:

Spoiler

Code:

Failed to enter SWD mode

chipid: 0x000
flash: 0
sram: 0
dev-type: unknown

Auch mit sehr niedriger SWD-Geschwindigkeit, verschiedenen Verbindungsversuchen und Connect-under-Reset ist keinerlei Zugriff möglich.

Damit ist für mich inzwischen ziemlich sicher, dass der STM32F429 mit einem entsprechend dauerhaft gesperrten Debug-Zugriff läuft.

Das passt auch zu den Informationen, die inzwischen aus anderen Quellen zu diesen FLY-Dongles bekannt sind.

Kurz gesagt:

Spoiler

Code:

STM32 läuft
USB funktioniert
Firmware arbeitet

aber:

kein normaler Debug-Zugriff
kein Flash-Dump über ST-Link
kein Zugriff über SWD

Ich habe zusätzlich mit einem Logic Analyzer mehrere der herausgeführten Pins während des Bootvorgangs und der Loader-Kommunikation mitgeschnitten.

Auch dort konnte ich bisher keinen einfachen UART-, SPI- oder sonstigen Bus finden, über den Firmware oder interessante interne Daten einfach übertragen werden.

Damit ist der einfache Weg über ST-Link und die normalen Debug-Schnittstellen für mich erst einmal beendet.

Deshalb geht es jetzt auf separater Testhardware weiter.

Die von mir bestellten STM32F429IGT6 Development Boards sind inzwischen angekommen und liegen jetzt auf dem Tisch.

Mein Plan ist, zunächst einen sauberen und vollständig reproduzierbaren Testaufbau mit diesen Boards zu erstellen.

Ich möchte nicht blind irgendwelche Experimente direkt am Dongle durchführen.

Wenn bei meinen Tests eines der Development Boards nicht mehr funktioniert, ist das verschmerzbar.

Beim Dongle wäre das natürlich deutlich ärgerlicher.

Als Nächstes möchte ich deshalb:

• Spoiler

  • STM32F429IGT6 Board und ST-Link sauber einrichten
  • eine eigene kleine Test-Firmware erstellen
  • Boot- und Reset-Verhalten dokumentieren
  • GPIO-Signale als Zeitmarken verwenden
  • UART für Debug-Ausgaben einrichten
  • Logic Analyzer und Oszilloskop synchron zum Startvorgang verwenden
  • verschiedene kontrollierte Start- und Fehlerzustände untersuchen
  • Flash-Inhalte und Zustände vor und nach den Versuchen vergleichen

  [*]

Die Test-Firmware soll dabei bewusst sehr einfach werden.

Ich möchte verschiedene Stellen während des Programmstarts über GPIO-Pins sichtbar machen.

Vereinfacht zum Beispiel:

Spoiler

Code:

RESET
  |
  v
BOOT START
  |
  v
GPIO 1
  |
  v
INIT
  |
  v
GPIO 2
  |
  v
MAIN

Damit kann ich mit Logic Analyzer und Oszilloskop relativ genau erkennen, wann der Controller welche Phase erreicht.

Mich interessiert dabei besonders:

Spoiler

• Wie verhält sich der STM32F429 direkt nach Reset?
• Welche Boot-Phasen lassen sich sauber über externe Signale erkennen?
• Wie reproduzierbar sind bestimmte Startzustände?
• Welche Unterschiede gibt es zwischen einem normalen und einem gestörten Start?
• Wie verhalten sich Reset, SWD und die laufende Firmware in unterschiedlichen Zuständen?

Mein Ziel ist zunächst, das Verhalten des STM32F429 auf meiner eigenen Testhardware möglichst gut zu verstehen und einen reproduzierbaren Messaufbau zu bekommen.

Erst wenn diese Abläufe sauber dokumentiert sind, werde ich die Ergebnisse mit dem Verhalten des Dongles vergleichen.

Parallel läuft natürlich weiterhin die Software- und USB-Analyse.

Bei der USB-Kommunikation sind wir inzwischen ein gutes Stück weiter.

Der Dongle arbeitet als Vendor-Specific HID-Gerät mit 64-Byte-Reports.

Die größeren Antworten werden über mehrere HID-Pakete fragmentiert übertragen.

Vereinfacht sieht die Kommunikation momentan ungefähr so aus:

Spoiler

Code:

Loader
  |
  v
Dongle Status
  |
  v
Device Information
  |
  v
Authentifizierung
  |
  v
weitere Freigabe / Session

Der Dongle ist damit definitiv nicht einfach nur ein passiver USB-Adapter.

Er verarbeitet aktiv Kommandos und liefert abhängig vom Kommunikationsablauf unterschiedliche Antworten.

Einige größere Antworten werden beispielsweise in mehreren Fragmenten übertragen.

Das sieht vereinfacht ungefähr so aus:

Spoiler

Code:

Fragment 1/3
Fragment 2/3
Fragment 3/3

Auch verschiedene Kommunikationsphasen zwischen Loader und Dongle lassen sich inzwischen relativ gut voneinander unterscheiden.

Genau deshalb bleibt der direkte Vergleich zwischen:

• Spoiler

  • meinem BOOT-Dongle
  • einem funktionierenden 23.x Dongle
  • dem neuen Lifetime-Dongle

  [*]

für mich weiterhin sehr interessant.

Was ich inzwischen ziemlich sicher sagen kann:

Der BOOT-Dongle ist nicht einfach elektrisch oder hardwareseitig tot.

Der STM32 läuft.

USB funktioniert.

Der Dongle verarbeitet weiterhin Kommandos.

Es findet weiterhin Kommunikation mit dem Loader statt.

Gleichzeitig ist der Controller so abgesichert, dass ein normaler Zugriff auf den internen Flash über die üblichen Debug-Schnittstellen nicht möglich ist.

Und genau hier liegt momentan die größte Blackbox.

Ohne einen verwertbaren Firmware-Stand kann man zwar USB, Loader und Serverkommunikation analysieren, aber die interne Logik des STM32 bleibt letztendlich unbekannt.

Mein langfristiges Ziel bleibt deshalb unverändert:

Ich möchte verstehen, was einen funktionierenden Dongle von einem BOOT-Dongle unterscheidet.

Erst mit entsprechenden Vergleichsdaten könnte man sauber untersuchen, ob der Unterschied beispielsweise in:

• Spoiler

  • Firmware
  • internem Gerätestatus
  • Lizenzdaten
  • Aktivierungsinformationen
  • einem anderen Speicherbereich
  • oder der Kombination mit dem FLY-Backend

  [*]

liegt.

Aktuell ist ein Teil davon weiterhin Theorie und genau deshalb versuche ich, möglichst viele unabhängige Messungen und Vergleichsdaten zu sammeln.

Falls ich mit dem Hardware- und Softwarevergleich überhaupt nicht weiterkomme, bleibt weiterhin mein Plan B.

Ich lasse den Dongle direkt über FLY aktualisieren bzw. wieder aktivieren.

Das entsprechende Angebot habe ich bereits erhalten.

FLY hat mir bestätigt, dass der Dongle gegen Bezahlung wieder aktualisiert bzw. aktiviert werden kann.

Falls es dazu kommt, werde ich den Zustand vor und nach dem offiziellen Vorgang möglichst sauber dokumentieren und vergleichen.

Mich interessiert dabei vor allem:

• Spoiler

  • Wird tatsächlich neue Firmware übertragen?
  • Verändert sich der interne Zustand des Dongles?
  • Werden lediglich Aktivierungsinformationen geändert?
  • Oder erfolgt die eigentliche Freigabe hauptsächlich über Loader und FLY-Backend?

  [*]

Danach sollte man zumindest deutlich besser verstehen, was bei diesen BOOT-Dongles tatsächlich passiert.

Aber bevor ich diesen Schritt mache, geht es jetzt erst einmal mit den STM32F429IGT6 Development Boards weiter.

Die Hardware ist angekommen.

Als Nächstes wird die erste Test-Firmware erstellt, GPIO-Zeitmarken gesetzt, UART eingerichtet und der komplette Startvorgang mit Logic Analyzer bzw. Oszilloskop dokumentiert.

Wenn der Testaufbau sauber und reproduzierbar läuft, kann ich die Beobachtungen Schritt für Schritt mit dem Dongle vergleichen.

Es bleibt also spannend.

Sobald die ersten Ergebnisse von den STM32F429IGT6 Boards vorliegen, gibt es das nächste Update.

Und noch einmal vielen Dank an alle, die mir bisher Daten, Informationen und Vergleichsmaterial geschickt haben.

Zum Vergrößern anklicken....

kral84 schrieb:

V26 deutsch funktioniert... mit dem loader

Zum Vergrößern anklicken....

jigga1986 schrieb:

Die 26 funktioniert mit dem loader im Ordner nicht

Zum Vergrößern anklicken....