Hallo liebe Forumgemeinde, kann mit dem ST-Link (SWD) und Coocox ein STM32 ausgelesen werden? Es geht um den Flashspeicher.. Ich möchte ein Programm runterladen als .hex oder .bin Kann mir jemand helfen?
Das kannst du mit der STM32 ST-LINK utility: http://www.st.com/web/en/catalog/tools/PF258168 Einfach verbinden und dann View->Device Memory anschliessend rechts klick auf den Device Memory Tab->Save to file
Danke für deine Antwort Pascal. Das Programm habe ich schon installiert und wird morgen ausprobiert. Ich denke das klappt. Danke. BTW: Hast du Erfahrungen mit der "Read-out-protection" der STM32-Controller? Im Kern geht es mir darum meinen Code zu schützen..
Hallo, das Programm "ST-LINK utility" habe ich installiert und kann nun den "Device Memory" vom STM32F051 auslesen und speichern. Ich habe ein sehr einfachen Testcode (Toggle LED) geschrieben den ich auslese und wieder auf den gelöschten Mikrocontroller laden möchte. Das klappt leider nicht, obwohl das Programm "ST-LINK utility" die grüne Meldung "Memory programmed in 0s and 858ms" ausgibt. Auch sonst gibt es keine Fehlermeldungen. Nur mein Testcode "Toggle LED" läuft eben nicht -> LED aus. Flashe ich es mit Coocox erneut blinkt die LED. Auch wenn ich das Orginal hex. oder .bin File von Coocox nehme und es mit ST-LINK utility flashe funktioniert es. Wieso funktioniert der 1:1 ausgelesene Code nicht??
STM-Bastler schrieb: > BTW: Hast du Erfahrungen mit der "Read-out-protection" der > STM32-Controller? > > Im Kern geht es mir darum meinen Code zu schützen.. Flash Option Bytes Beim Atmel SAM3X sperre ich den kompletten JTAG/SW Port, so dass überhaupt kein Zugriff per Debugger mehr möglich ist, ausser per Mass Erase Pin an der MCU.
:
Bearbeitet durch User
Hallo Random, "Flash Option Bytes" habe ich gefunden in der Software. Damit kann die "Read Out Protection" gesetzt werden.. Klingt erstmal vielversprechend. Mein Problem ist zunächst jedoch, dass ich unter Laborbedingungen meinen Code zwar irgendwie auslesen, aber nicht lauffähig wieder zurückspielen kann. Gibt es hierzu Erfahrungen? Ich möchte das Verfahren ja irgendwie testen.
>Ich möchte das Verfahren ja irgendwie testen.
Zu was?
Dein Vorhanden klingt irgendwie anders.
Hat denn das Transferprogramm kein "Verify", welches den tatsächlichen Speicherinhalt mit dem von dir geladenen Hex-File vergleicht?
:
Bearbeitet durch User
spontan schrieb: > Zu was? Test1 1. Controller auslesen 2. Controller löschen 3. Gelöschten Controller mit ausgelesenem hex/bin File beschreiben Test2 1. Controller beschreiben 2. read out setzen 3. Versuchen den Controller auszulesen Dachte mir, das wäre ne logische Vorgehensweise.. Karl Heinz schrieb: > Hat denn das Transferprogramm kein "Verify", welches den Speicherinhalt > mit dem von dir geladenen Hex-File vergleicht? Doch. Sagt mir auch immer "Verification...OK" nach dem Flashen. Mit dem STM32 ST-LINK Utility können auch zwei Files miteinander vergleichen werden. Und es sind tatsächlich Unterschiede da zwischen dem Orginal Coocox-Hex-File und dem Ausgelesenen Hex-File. Wird der Controller vielleicht nicht zu 100% ausgelesen?
STM-Bastler schrieb: > Wird der Controller vielleicht nicht zu 100% ausgelesen? Das wird dein "Problem" sein. Beim ST-Link Tool kannst du einstellen, wie viele Daten und von welcher Adresse er diese Lesen soll. Wenn du hier nicht genug liest, ist dein Programm hinterher natürlich nicht lauffähig. Das speichern speichert dann einfach nur den Bereich, den du ausgelesen hast. Mike
Hallo Mike, du hast mich auf die Lösung des Problems gebracht: Das "ST-LINK Utility" liest das lauffähige Programm von der Adresse 0x08000000 mit der Größe 0x0808 aus -> siehe Bild "a.png" ST-LINK Utility hat diese Einstellungen von "Adress" und "Size" selber gesetzt. Wenn dieses ausgelesene File nun wieder aufgespielt wird, fuktioniert es nicht! Erweitert man die Größe manuell auf z.B. 0x0812 -> siehe Bild "b.png" funktioniert das ausgelesene Programm beim erneuten Flashen! Danke für die Hilfen! Jetzt kann ich die "Read-Out-Protection" testen. Vielleicht muss ich mich dann hier nochmal melden ;-)
STM-Bastler schrieb: > Jetzt kann ich die "Read-Out-Protection" testen. Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du die Entwicklungsumgebung die Programmiersoftware die Hardware richtig benutzt?
STM-Bastler schrieb: > Jetzt kann ich die "Read-Out-Protection" testen. Ich dachte immer die Readout-Protection testet man mit etwas UV-Licht... ...bei geöffnetem Gehäuse... ...und mit einem guten Stereomikroskop und einer ruhigen Hand bei Malerarbeiten...
Route 66 schrieb: > STM-Bastler schrieb: >> Jetzt kann ich die "Read-Out-Protection" testen. > > Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du > die Entwicklungsumgebung die Programmiersoftware die Hardware > richtig benutzt? Das schöne bei den STM Controllern ist, das man die ReadOut Protection auch innerhalb der Firmware testen und setzen kann (löschen hab ich noch nicht probiert :) Und zu mindestens zu diesem Zweck möchte man sicher schon testen, ob die eigenen Routinen funktionieren.
Route 66 schrieb: > Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du > die Entwicklungsumgebung die Programmiersoftware die Hardware > richtig benutzt? Na ja, bis heute habe ich gedacht das ich die Einstellungen der Read-Out-Protection selber in meinem C-Code konfigurieren und einschalten muss. Es gibt hierzu ein Beispiel vom Hersteller -> stm32f0xx_flash.c Nicht gerade übersichtlich. Da wollte ich wissen ob meine Befehle im Programm funktionieren. Offensichtlich sieht das "ST-LINK Utility" eine einfache Möglichkeit diese Einstellungen vorzunehmen, ohne sich selber Code aus den Fingern saugen zu müssen :-) Oder bin ich wieder auf dem Holzweg?
Mike R. schrieb: > Das schöne bei den STM Controllern ist, das man die ReadOut Protection > auch innerhalb der Firmware testen und setzen kann (löschen hab ich noch > nicht probiert :) allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos löschen kann.
Das ST-Link Tool kann das Flags auch per Hand setzten. Aber im eigenen Quelltext ist das ganze in sofern sicherer, als das es nicht vergessen werden kann. Schreiber schrieb: > allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten > µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos > löschen kann. Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst das Bit zwar problemlos löschen, der Controller löscht dann aber den Flash auch gleich mit :-)
Mike R. schrieb: > Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst > das Bit zwar problemlos löschen, der Controller löscht dann aber den > Flash auch gleich mit :-) Jap.. Gerade getestet. Schon ab Level 1 geht nichts mehr mit auslesen. Es kann zwar der Schutz deaktivieren werden..aber wie Mike schon sagte ist der Code dann auch weg ;-) Ich glaube bei Level 2 geht auch nichts mehr mit Schutz deaktivieren. Der Controller ist dann zu. Das habe ich aber nicht getestet.. Ich werde mir trotzdem mal eine kleine lib für "Read-out-protection" schreiben..
Mike R. schrieb: > Schreiber schrieb: >> allerdings ist die Readout-Protection erfahrungsgemäß bei den meisten >> µCs weitestgehend wirkungslos, da man das zuständige Bit problemlos >> löschen kann. > > Meiner Erfahrung nach ist das bei ST schon recht gut gelöst. Du kannst > das Bit zwar problemlos löschen, der Controller löscht dann aber den > Flash auch gleich mit :-) stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: Schreiber schrieb: > Ich dachte immer die Readout-Protection testet man mit etwas UV-Licht... > ...bei geöffnetem Gehäuse... > ...und mit einem guten Stereomikroskop und einer ruhigen Hand bei > Malerarbeiten... dass es nicht im Datenblatt steht heißt eben nicht, dass es nicht geht!
Schreiber schrieb: > stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: Von außen ohne Zugriff auf das RAM zu haben, um von dort ein Programm einzuschleusen?
Route 66 schrieb: > STM-Bastler schrieb: >> Jetzt kann ich die "Read-Out-Protection" testen. > > Zeifelst Du an den Herstellerangaben oder willst Du nur wissen, ob Du > die Entwicklungsumgebung die Programmiersoftware die Hardware > richtig benutzt? Vertrauen ist gut - Kontrolle ist einfach besser! Das sehe ich genauso - wie STM-Bastler und würde auch erst alles durchtesten bevor die Firmware vermarktet wird. ;)
Schreiber schrieb: > stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: Wie geht das?
STM-Bastler schrieb: > Ich glaube bei Level 2 geht auch nichts mehr mit Schutz deaktivieren. > Der Controller ist dann zu. Das habe ich aber nicht getestet.. Ich habe mal zufällig Mode 2 anstatt Mode 1 verwendet. Ergebnis: Ich durfte den Chip runter löten und wegwerfen :-( Mode 2 funktioniert somit auch zuverlässig.
:
Bearbeitet durch User
Schreiber schrieb: > stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: Dann klär uns doch mal auf, wie das geht.
Guten Morgen, Mike R. schrieb: > Das ST-Link Tool kann das Flags auch per Hand setzten. Aber im eigenen > Quelltext ist das ganze in sofern sicherer, als das es nicht vergessen > werden kann. Ich möchte das auch gerne im Quelltext realisieren. Nun habe ich mich an das Verfahren in der stm32f0xx_flash.c gehalten. Klappt natürlich nicht. Ich habe den Verdacht, dass ich es mir wieder zu einfach vorstelle. Wenn ich das so programmiere ist mein "LED-Toggle-Programm" nicht lauffähig.. Kann mir jemand mal einen Tipp geben? Mike?
Ich gehe mal davon aus, dass du die Library von ST benutzt, meine Routinen besieren allerdings noch auf der alten Version, von daher hier mal der komplette Quelltext, der bei mir funktioniert: als erstes ein unlock
1 | void FLASH_Unlock(void) |
2 | {
|
3 | /* Authorize the FPEC of Bank1 Access */
|
4 | FLASH->KEYR = FLASH_KEY1; |
5 | FLASH->KEYR = FLASH_KEY2; |
6 | |
7 | #ifdef STM32F10X_XL
|
8 | /* Authorize the FPEC of Bank2 Access */
|
9 | FLASH->KEYR2 = FLASH_KEY1; |
10 | FLASH->KEYR2 = FLASH_KEY2; |
11 | #endif /* STM32F10X_XL */ |
12 | }
|
und dann das setzen
1 | /**
|
2 | * @brief Enables or disables the read out protection.
|
3 | * @note If the user has already programmed the other option bytes before calling
|
4 | * this function, he must re-program them since this function erases all option bytes.
|
5 | * @note This function can be used for all STM32F10x devices.
|
6 | * @param Newstate: new state of the ReadOut Protection.
|
7 | * This parameter can be: ENABLE or DISABLE.
|
8 | * @retval FLASH Status: The returned value can be: FLASH_ERROR_PG,
|
9 | * FLASH_ERROR_WRP, FLASH_COMPLETE or FLASH_TIMEOUT.
|
10 | */
|
11 | FLASH_Status FLASH_ReadOutProtection(FunctionalState NewState) |
12 | {
|
13 | FLASH_Status status = FLASH_COMPLETE; |
14 | /* Check the parameters */
|
15 | assert_param(IS_FUNCTIONAL_STATE(NewState)); |
16 | status = FLASH_WaitForLastOperation(EraseTimeout); |
17 | if(status == FLASH_COMPLETE) |
18 | {
|
19 | /* Authorizes the small information block programming */
|
20 | FLASH->OPTKEYR = FLASH_KEY1; |
21 | FLASH->OPTKEYR = FLASH_KEY2; |
22 | FLASH->CR |= CR_OPTER_Set; |
23 | FLASH->CR |= CR_STRT_Set; |
24 | /* Wait for last operation to be completed */
|
25 | status = FLASH_WaitForLastOperation(EraseTimeout); |
26 | if(status == FLASH_COMPLETE) |
27 | {
|
28 | /* if the erase operation is completed, disable the OPTER Bit */
|
29 | FLASH->CR &= CR_OPTER_Reset; |
30 | /* Enable the Option Bytes Programming operation */
|
31 | FLASH->CR |= CR_OPTPG_Set; |
32 | if(NewState != DISABLE) |
33 | {
|
34 | OB->RDP = 0x00; |
35 | }
|
36 | else
|
37 | {
|
38 | OB->RDP = RDP_Key; |
39 | }
|
40 | /* Wait for last operation to be completed */
|
41 | status = FLASH_WaitForLastOperation(EraseTimeout); |
42 | |
43 | if(status != FLASH_TIMEOUT) |
44 | {
|
45 | /* if the program operation is completed, disable the OPTPG Bit */
|
46 | FLASH->CR &= CR_OPTPG_Reset; |
47 | }
|
48 | }
|
49 | else
|
50 | {
|
51 | if(status != FLASH_TIMEOUT) |
52 | {
|
53 | /* Disable the OPTER Bit */
|
54 | FLASH->CR &= CR_OPTER_Reset; |
55 | }
|
56 | }
|
57 | }
|
58 | /* Return the protection operation Status */
|
59 | return status; |
60 | }
|
danach resete ich den Controller (weiß aber nicht, ob das unbedingt nötig ist) Was du evtl. auch noch schauen mußt, sind die Clock Einstellungen. Ich weiß gerade nicht, ob man eine Clock aktivieren muss, damit man im Option Byte schreiben kann. Mike
Hallo, danke für deine Routine Mike. Ich habe jetzt meinen Fehler gefunden.. Denke ich. Mein Programm hat die Read-Out-Protection schon richtig gesetzt. JEDESMAL beim Starten des Controllers. Inklusive eines System-reset. Das Programm ist also nie zum Mainloop gekommen. Mit einer Abfrage ob die Read-Out-Protection schon gesetzt ist, setze ich jetzt nur EINMAL den Schutz. Ab nun überspringt er das Setzen vom Schutz und vor allem den System-Reset. Mike R. schrieb: > danach resete ich den Controller (weiß aber nicht, ob das unbedingt > nötig ist) Das macht die Funktion FLASH_OB_Launch(); und ist wohl nötig. Mike R. schrieb: > Was du evtl. auch noch schauen mußt, sind die Clock Einstellungen. Ich > weiß gerade nicht, ob man eine Clock aktivieren muss, damit man im > Option Byte schreiben kann. Nein. Läuft bei mir so. Das Datenblatt schreibt was von internem RC-Clock. Ich denke solange da eine Clock aktiv ist, läuft das (...) Mike R. schrieb: > Schreiber schrieb: > >> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: > > Dann klär uns doch mal auf, wie das geht. Ich glaube da kommt nichts mehr. Man findet schon einiges im Netz zum Hacken von Controllern.. Zum Teil auch Angebote von Firmen die sich drauf spezialisiert haben. Ich stelle mal die These auf, dass mit viel Aufwand sowas möglich ist. Genau wie man in ein Haus einbrechen kann, welches sehr gut geschützt ist. Wenn ich mein Haus aber garnicht erst abschließe, sondern alle Türen offen lasse, muss der Dieb sich nicht anstrengen was zu klauen. Für "normale" Programmierer denke ich das es nicht möglich ist den geschützen Controller auszulesen.
STM-Bastler schrieb: > Ich stelle mal die These auf, dass mit viel Aufwand sowas möglich ist. > Genau wie man in ein Haus einbrechen kann, welches sehr gut geschützt > ist. Wenn ich mein Haus aber garnicht erst abschließe, sondern alle > Türen offen lasse, muss der Dieb sich nicht anstrengen was zu klauen. > > Für "normale" Programmierer denke ich das es nicht möglich ist den > geschützen Controller auszulesen. Die Frage ist eben, vor wem willst Du Dich schützen. Ist dein Code soviel Wert, dass jemand entsprechende Spezialisten beauftragt.
Mike R. schrieb: >> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: > > Dann klär uns doch mal auf, wie das geht. eigentlich ganz einfach: 1. Gehäuse vom Chip öffnen, üblicherweise mit etwas Salpetersäure und Aceton 2. betreffendes Bit suchen 3. den rest vom Chip vorsichtig mit schwarzer Farbe bemalen 4. Chip unter UV-Lampe legen, ggf. hierzu schräg stellen/legen 5. Programm mit handelsüblichem Programmiergerät auslsen 6. fertig Das ganze gibts als Komplettangebot von einigen Dienstleistern für viele µCs zu erträglichen Konditionen (ab 500€), kann aber auch in einem besser ausgestatteten Bastelkeller/Hobbylabor durchgeführt werden
Steffen Rose schrieb: > Die Frage ist eben, vor wem willst Du Dich schützen. Ist dein Code > soviel Wert, dass jemand entsprechende Spezialisten beauftragt. Nein, der ist nicht so viel Wert. Es wird niemand deswegen einen Spezialisten beauftragen. Aber das "Schloß zum Abschließen der Tür" kostet mich ja nichts ;-) und somit bleiben die "Gelegenheitsdiebe" erfolglos. Jetzt steht der Code und es funktioniert. Das ist was ich erreichen wollte. Danke euch!
Mike R. schrieb: > Schreiber schrieb: > >> stimmt so nicht, man kann das Bit löschen ohne den Flash zu löschen: > > Dann klär uns doch mal auf, wie das geht. Indem Du ein paar Scheine locker machst und dich mit der Firma da: http://russiansemiresearch.com/en/service/ in Verbindung setzt.
STM-Bastler schrieb: > Für "normale" Programmierer denke ich das es nicht möglich ist den > geschützen Controller auszulesen. Es wird ja auch nicht gemacht wenn man Programmierer hat oder gar von Programmierern selbst (Programmierer würden sowas nie tun, die nehmen ja oft nichtmal fertigen Code selbst wenn er verfügbar ist weil er immer schlechter wäre als das was man selber machen könnte) sondern wenn man gerade eben KEINE Programmierer hat weil man keine bezahlen will und stattdessen lieber kurzerhand das teure Konkurrenzprodukt 1:1 klont.
Hallo, ich möchte einen STM32 auslesen, bekomme aber nur FFFF heißt das ich habe versehentlich das Programm gelöscht? Ich habe lediglich in den Option Bytes die Readout Protection auf disabled gestellt, wusste nicht dass ich damit den STM32 lösche? wie muss ich die Adresse und Länge angeben zum auslesen des Programms? Hab heut zum ersten Mal sowas in der Mangel.
Alexander schrieb: > Readout Protection Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so umgehen könnte. keinen
Stefan F. schrieb: > Alexander schrieb: >> Readout Protection > > Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so > umgehen könnte. einfach ist relativ, oben wurden ja ein paar einschlägige Firmen und Preise erwähnt. Seit 2015 ist auch das billiger geworden, z.B.: https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/
verdammmt, ich wollte nur ein Backup machen bevor ich was flashe. egal. an welche Adresse muss man das hexfile flashen, oder steht das in der Datei selbst? hab es aus diesem Internet heruntergeladen, also irgendwer hat das irgendwie schon mal ausgelesen.
Alexander schrieb: > Hallo, ich möchte einen STM32 auslesen, bekomme aber nur FFFF heißt das > ich habe versehentlich das Programm gelöscht? Ich habe lediglich in den > Option Bytes die Readout Protection auf disabled gestellt, wusste nicht > dass ich damit den STM32 lösche? wie muss ich die Adresse und Länge > angeben zum auslesen des Programms? Hab heut zum ersten Mal sowas in der > Mangel. Hallo Alexander, wie hast du das hin bekommen? Ich will einen STM32 mit aktivieren RDP Level 2 lediglich neu flashen, daher ist es OK, wenn der Flash bei der Aktion gelöscht wird. Hintergrund ist ein Verdrahtungsfehler am Boot0, welcher sich zwar mit Readout-Protection Level 2 umgehen lässt mit den entsprechenden Nachteilen. Beste Grüße Uwe
Stefan F. schrieb: > Überlege mal welchen Sinn diese Funktion hätte, wenn man sie einfach so > umgehen könnte. Angeblich ist das gaz einfach: Schreiber schrieb: > eigentlich ganz einfach ... > 2. betreffendes Bit suchen > 3. den rest vom Chip vorsichtig mit schwarzer Farbe bemalen > kann in einem besser ausgestatteten Bastelkeller/Hobbylabor durchgeführt werden Dem hatte noch niemand widersprochen, was ich hiermit nachhole: Das das so einfach geht, bezweifle ich. Wie malt man denn schwarze Farbe auf einzelne Bits? Mit einem Schweineborsten-Pinsel? Schreiber schrieb: > Das ganze gibts als Komplettangebot von einigen Dienstleistern für viele > µCs zu erträglichen Konditionen (ab 500€) Aktuell ab $2900 für STM32. Ich fürchte allerdings, dass die das Geld nehmen und sich dann nie wieder melden.
Da SWD bei mir deaktiviert war, klappte es nur mittels Bootloader. D.h. ich habe solange probiert bis es geklappt hat. STM32 stromlos, 3V3 mit ST Link v2 (Klon) verbunden, in den USB-Port eingesteckt und fast gleichzeitig im ST-Link Utility auf 'Verbinden' geklickt. Mit dem richtigen Timing klappt das. Als es irgendwann verbunden war habe ich dann einfach in den Option Bytes die Readout-Protection deaktiviert, das ging problemlos. Welches Level das war kann ich Dir nicht sagen. Einen Reset-Pin habe ich dazu nicht verlötet.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.