- 19 August 2021
- 2.717
- 5.757
- E-Scooter
- mi Pro2/9bot F2 Pro
Es haben mich in der letzten Zeit vermehrt Leute kontaktiert die den Chip Swap scheinbar als Privatperson gemacht haben.
Nun stehen sie aber alle vor dem gleichen Problem wie ich zu Anfang.
Also möchte ich hier jetzt den Guide komplett machen.
Um den Chip-Swap funktionabel zu bekommen, muss ebenfalls noch ein TPS_ENA swap gemacht werden.
Wie man auf diesem Bild sehen kann, muss dafür der PB3 Pin entfernt, und eine Verbindung von dem PA11 Pin zu dem pad wo der PB3 Pin vorher war hergestellt werden.
Warum ist das so ?
Die DRV Firmware liest einen bestimmten Speicherbereich des Mikrocontroller aus auf dem sie läuft.
In diesem Speicherbereich liegt die Device_id des Chip.
An Hand dieser Device_id, stellt die Firmware fest worauf sie gerade ausgeführt wird.
Ob auf einem Artery oder STM32 Chip.
Der PB3 Pin war bei den alten Controller Platinen mit STM32 Chip ein unbenutzter, von der Firmware mit UART angesteuerter Pin.
Auf den neuen v1.1 Controllern mit AT32F415 Chips ist dieser Pin aber nun für das TPS_ENA Signal vorgesehen.
Das TPS_ENA Signal ist für das ein und ausschalten des Controller zuständig.
Wenn der Controller eingeschaltet ist, liegt an dem TPS_ENA Schaltkreis Spannung an.
Da die Firmware aber an Hand der in dem Mikrocontroller eingebrannten device_id feststellt das sie momentan auf einem STM32 Chip läuft,
geht sie davon aus das es noch ein alter Controller ist.
Somit steuert sie diesen Pin weiterhin mit dem besagten UART, aber nicht mit dem eigentlich benötigten TPS_ENA Signal an.
Dadurch das der Pin aber nun zu dem TPS_ENA Schaltkreis auf der neuen Platine führt und dort Spannung anliegt, wird das UART Signal gestört.
Wenn das UART Signal gestört wird, kann der Controller aber nicht mehr mit dem Dashboard via UART kommunizieren.
Deswegen zeigt die BLE Firmware des Dashboard den Fehler 10 auf dem Display.
Sie ruft quasi um Hilfe.
Um den Fehler zu beheben, müssen wir für den Chip also die gleichen Voraussetzungen schaffen, als wenn er auf einer alten Controller Platine sitzt und den PB3 pin von dem TPS_ENA Schaltkreis trennen.
Nun wird das UART Signal nicht mehr gestört.
Aber es muss auch noch der PA11 Pin welcher bei den STM32 Chips für das TPS_ENA Signal zuständig ist auf das Pad des entfernten PB3 Pin gelegt werden.
Erst dann hat der alte TPS_ENA Pin kontakt zu dem neuen TPS_ENA Schaltkreis auf der Platine und kann das ein und Ausschalten steuern.
PS:
Ich öffne den Thread mal wieder damit bei Problemen Fragen gestellt werden können.
Happy Chip und TPS_ENA swapping.
Nun stehen sie aber alle vor dem gleichen Problem wie ich zu Anfang.
Also möchte ich hier jetzt den Guide komplett machen.
Um den Chip-Swap funktionabel zu bekommen, muss ebenfalls noch ein TPS_ENA swap gemacht werden.
Wie man auf diesem Bild sehen kann, muss dafür der PB3 Pin entfernt, und eine Verbindung von dem PA11 Pin zu dem pad wo der PB3 Pin vorher war hergestellt werden.
Warum ist das so ?
Die DRV Firmware liest einen bestimmten Speicherbereich des Mikrocontroller aus auf dem sie läuft.
In diesem Speicherbereich liegt die Device_id des Chip.
An Hand dieser Device_id, stellt die Firmware fest worauf sie gerade ausgeführt wird.
Ob auf einem Artery oder STM32 Chip.
Der PB3 Pin war bei den alten Controller Platinen mit STM32 Chip ein unbenutzter, von der Firmware mit UART angesteuerter Pin.
Auf den neuen v1.1 Controllern mit AT32F415 Chips ist dieser Pin aber nun für das TPS_ENA Signal vorgesehen.
Das TPS_ENA Signal ist für das ein und ausschalten des Controller zuständig.
Wenn der Controller eingeschaltet ist, liegt an dem TPS_ENA Schaltkreis Spannung an.
Da die Firmware aber an Hand der in dem Mikrocontroller eingebrannten device_id feststellt das sie momentan auf einem STM32 Chip läuft,
geht sie davon aus das es noch ein alter Controller ist.
Somit steuert sie diesen Pin weiterhin mit dem besagten UART, aber nicht mit dem eigentlich benötigten TPS_ENA Signal an.
Dadurch das der Pin aber nun zu dem TPS_ENA Schaltkreis auf der neuen Platine führt und dort Spannung anliegt, wird das UART Signal gestört.
Wenn das UART Signal gestört wird, kann der Controller aber nicht mehr mit dem Dashboard via UART kommunizieren.
Deswegen zeigt die BLE Firmware des Dashboard den Fehler 10 auf dem Display.
Sie ruft quasi um Hilfe.

Um den Fehler zu beheben, müssen wir für den Chip also die gleichen Voraussetzungen schaffen, als wenn er auf einer alten Controller Platine sitzt und den PB3 pin von dem TPS_ENA Schaltkreis trennen.
Nun wird das UART Signal nicht mehr gestört.
Aber es muss auch noch der PA11 Pin welcher bei den STM32 Chips für das TPS_ENA Signal zuständig ist auf das Pad des entfernten PB3 Pin gelegt werden.
Erst dann hat der alte TPS_ENA Pin kontakt zu dem neuen TPS_ENA Schaltkreis auf der Platine und kann das ein und Ausschalten steuern.
PS:
Ich öffne den Thread mal wieder damit bei Problemen Fragen gestellt werden können.
Happy Chip und TPS_ENA swapping.

Zuletzt bearbeitet: