D4R-II flashen, STM32 neu, Via inverted FTDI -> FRSKY Updater machts nicht!

[schuerni]

Hallo. Ich habe einen D4r-II der mal verpolt wurde.
Der STM32 war hin und wurde sauberst unterm Mikroskop getauscht. Das habe ich nun schon öfters gemacht, bisher bei FCs wie Naze32 und Flip32 und es hat jedes Mal geklappt.
Nun habe ich aber das Problem, dass der D4R-II FRSKy-Updater via Inverted FTDI den Empfänger nicht erkennt (klar, der STM32 ist ja auch krachneu, also ohne FRSKY Bootloader), ich aber auch kein hex-file finde um den per STLink zu flashen.
Also, hat jemand ne Idee? bzw ein .hex File? Wie ist das mit Opensky? hab ich keine Ahnung davon...
Frsky liefert nur ein .FRk File, das nach Umbenennung als "korrupted" erkannt wird.
Gruss Karsten

 

[schuerni]

Ich habe jetzt den STLink Programmer direkt an die Beinchen 34 / 37 des STM32 gelötet,
SWCLK und SWDIO und habe auch Kommunikation mit dem Chip.
Was ich also jetzt brauche ist das korrekte .hex File für den Empfänger.
Kann mir da jemand helfen?
Grüsse Karsten

 

[Elyot]

Das Hex-File ist leider nicht frei verfügbar. Du kannst aber evtl. OpenSky flashen.

 

[Nico_S_aus_B]

... Das habe ich nun schon öfters gemacht, bisher bei FCs wie Naze32 und Flip32 und es hat jedes Mal geklappt.

Das glaube ich dir gerne, aber bei denen hat man auch eine unverschlüsselte Firmware!

Nun habe ich aber das Problem, dass der D4R-II FRSKy-Updater via Inverted FTDI den Empfänger nicht erkennt (klar, der STM32 ist ja auch krachneu, also ohne FRSKY Bootloader), ich aber auch kein hex-file finde um den per STLink zu flashen.

Das Problem ist nicht lösbar.
Zwar werden alle STM-MCUs mit dem STM-eigenen Bootloader ausgeliefert und mit dem kann man dann auch kommunizieren, nur nützt das nichts.
Denn FrSky hat in seiner unendlichen Weisheit beschlossen, nur verschlüsselte Firmware (eben die besagten .frk-Dateien) zu Verfügung zu stellen. Die Entschlüsselungsroutine sitzt irrsinnigerweise direkt in der Firmware (die ja als Datei nur verschlüsselt zu bekommen ist).
Mit anderen Worten: Solange man keine unverschlüsselte .bin- oder .hex-Datei erhält (was man nach allen bisherigen Berichten als nahezu unmöglich bezeichnen kann), kann man einen FrSky-Empfänger nicht wiederbeleben.
Das Problem haben z.B. auch viele gebeutelte Benutzer, deren FrSky-Empfänger durch einen fehlgeschlagenen Flash-Vorgang "gestorben" ist. Die Hardware ist völlig intakt, nur kommt man um's Verrecken nicht an die nötige unverschlüsselte Firmware...

Es ist so ein Henne-Ei-Problem.

 

[kalle123]

Zu opensky. Das

DO NOT use this software to control real planes/quadrocopters.
This is for educational use only, bad things could happen if you run this on a real vehicle. Its meant to be used on indoor and/or small vehicles.
Using this code will probably void its FCC compliance and might void transmission laws depending on your country!

hast du gesehen?

Gruß KH

 

[Elyot]

Ich habe OpenSky auf einem VD5M problemlos am Laufen. Zudem nutzen das inzwischen auch schon diverse AIO-FCs und China-Empfänger. Bei OpenTX fliegen auch viele mit Beta-Software. Dann müßte man schon dort ansetzen. Pauschal ablehnen ist daher übertrieben. Überlegen, in welchem Modell man das betreibt, sollte man aber.

 

[kalle123]

Überlegen, in welchem Modell man das betreibt, sollte man aber.

Steht ja hier groß und breit

Its meant to be used on indoor and/or small vehicles.

cu KH

 

[schuerni]

Aha, das ist ja interessant, also verstehe ich das richtig dass ich kein .hex im Netz finden werde?
Was ist wenn ich einen lebenden Empfänger an den STLink hänge und das .hex auslese?
Das müsste ich doch machen können und so wieder auf einen anderen draufballern?
Ansonsten Opensky, jaklar, zumindest als Baubrett-Empfänger bzw. für die DopeRind-Klasse, oder?
Ich hatte mal Opensky runtergeladen, bekomms aber nicht ans Laufen. kann mir jemand evtl. ein .hex kompilieren?
Grüsse...

 

[Elyot]

Auslesen ist nicht so einfach, sonst gäbe es das Hex schon im Netz.

 

[schuerni]

Habs grad gemerkt..... lebenden Empfänger angelötet.... STlink dran.

"Can not read memory"
"Disable readout protection and retry"

Weiss einer wie das geht??

 

[Arakon]

Auslesen ist sogar ziemlich unmöglich, die Chips sind dafür lesegeschützt.
Ich kann evtl. heute abend Opensky mal kompilieren. Ich benutz das auf nem D4R-II seit ner Weile, absolut ohne Probleme. Das richtig Tolle daran: Damit kann auch der D4R-II SBUS.

 

[Elyot]

Den Ausleseschutz kannst Du bei diversen ausländischen Firmen für ab 2000 € entfernen lassen. Das Hex gibts dann meist gratis dazu.

 

[Nico_S_aus_B]

Aha, das ist ja interessant, also verstehe ich das richtig dass ich kein .hex im Netz finden werde?

So ist es (leider)!

Was ist wenn ich einen lebenden Empfänger an den STLink hänge und das .hex auslese?
Das müsste ich doch machen können und so wieder auf einen anderen draufballern?

Das geht leider nicht, weil die Dinger lesegeschützt sind. Und die Entfernung des tollen Leseschutzes ist nur bei gleichzeitiger Löschung des Speichers möglich.
Man hat uns also alle Steine in den Weg gelegt, die man finden konnte...

 

[schuerni]

Ich hab gelesen, dass man die Readout Protection (zumindest lvl1) per J-Link entfernen kann, aber ich hab dafür keinen Programmer. Hhhm... Hab auch nix gefunden den mal kurz z.B. ausm STM Evo Board zu "machen".

Danke fürs Kompilieren, freu mich schon drauf.
Ich schick Dir gleich mal ne PN mit mailadresse etc...
Gruss... Karsten

 

[schuerni]

Hhhm... hab grad das Problem verdoppelt....
In der STlink-Utility gibts unter "Option Bytes" die Möglichkeit die ReadOutProtection zu disabeln.
Haken gesetzt, Apply gedrückt, kompletter STM32 Memory enthält jetzt "FFFFFFFF"
ScheiXXX!! Könnt schonmal vorher ne Warnung kommen "You are about to erase ev-uh-erything.." oder so.....
Damit hat sich die Option erübrigt das .hex File da irgendwie rauszubekommen.
Ich freue mich also schonmal doppelt auf Arakons Opensky .hex ;-))
Gruss Karsten

 

[Arakon]

Ja.. das ist der Punkt von dem Schutz, eben damit man nicht einfach den Code kopieren kann und Clones basteln kann. Leseschutz entfernen geht nur, wenn dabei der Code vorher gelöscht wird.
Erinner mich morgen Abend nochmal dran, falls ich es heute Abend verpenne.

 

[Nico_S_aus_B]

In der STlink-Utility gibts unter "Option Bytes" die Möglichkeit die ReadOutProtection zu disabeln.
Haken gesetzt, Apply gedrückt, kompletter STM32 Memory enthält jetzt "FFFFFFFF"

Na ja, das ist eben genau so vorgesehen. Man will ja um alles in der Welt verhindern, dass jemand an die Firmware drankommt.
Die Warnung steht vielleicht nicht in der Software, aber im Datenblatt ist das sehr genau und unmissverständlich beschrieben!

 

[schuerni]

Man lernt immer dazu
Naja, da die beiden Empfänger sowieso im 250gr DopeRind geflogen werden sollen ist mir die SBUS Variante sehr recht
und das Schadenpotenzial auch abschätzbar
Danke vorab Arakon und bis heute Abend.
Gruss

 

[schuerni]

Sodele..... Opensky flashen war erfolgreich, auch wenns Probleme gibt, sowohl noninverted als auch inverted mit der Naze32 StmF1 zu lesen, die reagiert nämlich gar nicht, hats mit dem F3 auf dem Pico Blx geklappt.
Da ich die Empfänger jetzt sowieso nur in der DopeRind Klasse einsetzen will passt das auch.
Nur:
Wie bekomm ich jetzt am A1 (laut Opensky am ExtensionPort "Pin[2] ADC1 input (max 3.3V!)") die Akkuspannung in die Taranis?
Die findet nämlich keinen Sensor. bzw findet Sie 2 davon, der eine zeigt konstant "0" der andere konstant 5.6V.
HHhmmm
Gruss

 

[schuerni]

Habs hinbekommen, der A2 mit "0" wars....
Irgendwo auf der Empfängerplatine war ein Zinnhäärchen mir Brücke auf Masse und hat den A2 auf "0" gezogen.
Kurz nachgelötet -> geht.
Ich kann bisher Opensky empfehlen!
Hab vorhin 3 Akkus durchgeballert und merke keinen Unterscheid zum Bruder-GEP-copter mit einem X4R drinne.
Grüsse...
Karsten