Ich versuche die ITM Schnittstelle auf dem Nucleo STM32H743 mit Keil MDK5 zum Laufen zu bringen. Bisher ohne Erfolg. Auf anderen Boards (L432, L476 etc) klappt das ohne Probleme. TM32DBG.ini als Initialisierung, die Ports entsprechend gesetzt, retarget.c dazu. Fehlt beim H7 noch irgendwas ? Danke
Dem H7 traue ich noch nicht so richtig ueber den Weg. Vermutlich sind fuer ITM noetige Bits noch nicht (oeffentlich) dokumentiert, oder es fehlt die (oeffentliche) Dokumentation von Bugs...
das hat beim F7 schon nicht sauber funktioniert ... lösung lief immer über den AXI mit cache ...
Also irgendwie habe ich es geschafft, auf diesem Nucleo-Bord den Controller zu zerschiessen (software). Er lässt sich nicht mehr flashen, einige Pages seien geschützt. Ich kann auch den schreibschutz nicht aufheben. Chip Erase geht auch nicht. Völlig „verfused“ würde man beim AVR sagen. Hat jemand n Tip wie ich den Controller retten kann? Hatte zum glück noch n zweites Nucleo davon. Würde es ungern in die Tonne treten. Anfangs lief es. Dann lief irgendwas beim Flashen falsch, St-Link Utility is abgeschmiert. Seit dem geht nichts mehr auf der Karre
Ingo Less schrieb: > Also irgendwie habe ich es geschafft, auf diesem Nucleo-Bord den > Controller zu zerschiessen (software). Ich hoffe die STler haben ein großes Interesse an deinem verfuseten Board - sofern du es nicht misshandelt hast(Überspannung, etc). Frag sie mal!
Ingo Less schrieb: > Also irgendwie habe ich es geschafft, auf diesem Nucleo-Bord den > Controller zu zerschiessen (software). Er lässt sich nicht mehr flashen, > einige Pages seien geschützt. Ich kann auch den schreibschutz nicht > aufheben. Chip Erase geht auch nicht. Völlig „verfused“ würde man beim > AVR sagen. Hat jemand n Tip wie ich den Controller retten kann? Hatte Da bleibt wohl nur die Hoffnung, alle Option-Bits mit den Defaults zu vergleichen, ebenso die PCROP- und die "Secure-Protection"-Register und diese ggf. manuell wieder auf die Defaults zurück zusetzen. Mir ist so etwas mit der STLink-Software und einem der Watchdogs passiert, das Bit ließ sich damit partout nicht mehr in den Ursprungszustand zurück versetzen. Die "händische" Deaktivierung mittels openOCD hat aber doch recht einfach geklappt.
Nur so als Frage: wie verhält sich das Board mit dem STM32CubeProgrammer? http://www.st.com/en/development-tools/stm32cubeprog.html
Keine Chance, geht auch damit nicht... Weitere Rettungsvorschläge?
Morgen, was heisst geht nicht? Hast du die verschiedenen "Reset Mode" durch probiert?
Alles durchprobiert. Es scheitert am verify bzw. lesen des Flashes. Das Programm läuft auch nicht. Gleiches Programm auf nem anderen Bord läuft. pegel schrieb: > und "OB" ? Option Bytes? Hier lässt sich der Schreibschutz nicht deaktivieren 08:04:34 : Option byte command : -ob DMEP1=0 DMEP2=0 08:04:34 : PROGRAMMING OPTION BYTES AREA ... 08:04:34 : Bank : 0x00 08:04:34 : Address : 0x5200201c 08:04:34 : Size : 308 Bytes 08:04:34 : UPLOADING OPTION BYTES DATA ... 08:04:34 : Bank : 0x00 08:04:34 : Address : 0x5200201c 08:04:34 : Size : 308 Bytes 08:04:34 : OPTION BYTE PROGRAMMING VERIFICATION: 08:04:34 : Error: Expected value for Option Byte "DMEP1": 0x0, found: 0x1 08:04:34 : Error: Expected value for Option Byte "DMEP2": 0x0, found: 0x1
:
Bearbeitet durch User
Habe versucht die PROT_AREA zu ändern, er lässt keine Änderungen zu: 08:06:23 : Option byte command : -ob PROT_AREA_START1=0xff PROT_AREA_START2=0xff DMEP2=0 DMEP1=0 08:06:23 : PROGRAMMING OPTION BYTES AREA ... 08:06:23 : Bank : 0x00 08:06:23 : Address : 0x5200201c 08:06:23 : Size : 308 Bytes 08:06:23 : UPLOADING OPTION BYTES DATA ... 08:06:23 : Bank : 0x00 08:06:23 : Address : 0x5200201c 08:06:23 : Size : 308 Bytes 08:06:23 : OPTION BYTE PROGRAMMING VERIFICATION: 08:06:23 : Error: Expected value for Option Byte "DMEP1": 0x0, found: 0x1 08:06:23 : Error: Expected value for Option Byte "DMEP2": 0x0, found: 0x1 08:06:23 : Error: Expected value for Option Byte "PROT_AREA_START1": 0xFF, found: 0x0 08:06:23 : Error: Expected value for Option Byte "PROT_AREA_START2": 0xFF, found: 0x0 Wäre echt über jede Hilfe dankbar...
:
Bearbeitet durch User
Es war kein H7, aber ich hatte auch mal einen störrischen µC. Durch mehrfaches probieren mit "Reset Mode" und "Full Erase" und "OB" habe ich ihn wieder belebt. Ansonsten wäre vielleicht doch das ST Forum die erste Wahl.
Ingo L. schrieb: > Habe versucht die PROT_AREA zu ändern, er lässt keine Änderungen > zu: > > 08:06:23 : Option byte command : -ob PROT_AREA_START1=0xff > PROT_AREA_START2=0xff DMEP2=0 DMEP1=0 > 08:06:23 : Error: Expected value for Option Byte "DMEP1": 0x0, found: > 0x1 > 08:06:23 : Error: Expected value for Option Byte "DMEP2": 0x0, found: > 0x1 > 08:06:23 : Error: Expected value for Option Byte "PROT_AREA_START1": > 0xFF, found: 0x0 > 08:06:23 : Error: Expected value for Option Byte "PROT_AREA_START2": > 0xFF, found: 0x0 Tja, da sind offensichtlich beide Bänke komplett PCROPped, denn PROT_AREA_START == PROT_AREA_END (letztere ist wohl noch auf dem Default 0) heißt genau das. Also nicht lesbar, das ist ja auch der Sinn der Sache. Da bleiben wohl nur die beiden Möglichkeiten, die im RM auf S. 136 unten beschrieben sind. Und es wäre nicht überraschend, wenn das mit der ST-Software (noch) nicht geht, da dort nicht vorgesehen oder nicht vollständig bzw. nicht korrekt implementiert. Da wird man wohl oder übel manuell Register für Register über 'nen Debugger schreiben müssen. Und das sorgfältigst, denn ein Fehler beim RDP-Level und das war's dann ...
A. B. schrieb: > Da wird man wohl oder übel manuell Register für Register über 'nen > Debugger schreiben müssen. Und das sorgfältigst, denn ein Fehler beim > RDP-Level und das war's dann ... Also was mich da wundert is, dass man solch einen Mechanismus nicht mit einem Full-Chip-Erase platt gemacht bekommt! Was soll denn so ein Unsinn???
Ingo L. schrieb: > Also was mich da wundert is, dass man solch einen Mechanismus nicht mit > einem Full-Chip-Erase platt gemacht bekommt! Was soll denn so ein > Unsinn??? Es soll halt besonders sicher sein ... Für mich heißt das Finger weg von PCROP, Secure-Mode und RDP. Und im Errata Sheet dann das Bonbon: "PCROP-protected areas in Flash memory might be unprotected Description In case of readout protection level regression from level 1 to level 0, the PCROP protected areas in Flash memory might become unprotected. Workaround The user application must set the readout protection level to level 2 to avoid PCROP-protected areas from being unprotected." Das kann/muss man wohl so interpretieren, dass die Rev. Y nicht so ganz gereift ist. Überhaupt ist dieses PCROP m. E. ein schlecht durchdachtes Gewurschtel, da damit selbst PC-relative Lesezugriffe nicht möglich sind. Das erfordert einige Klimmzüge.
Juuuunge, ich habs endlich wieder hin bekommen. Hier ne funktionierende Reihenfolge (SWD 100kHz): Verbinden (gibt ne Fehlermeldung) - Read-out-protection von 0xAA auf 0xBB stellen (klappt nur direkt nach dem Verbinden - Verbindung trennen - Verbindung neu aufbauen - RDP von 0xBB auf 0xAA UND dabei Schritt für Stück die Option-Bytes wieder aufbauen. Klappt auch immer nur für einen Parameter. Dann selbes Prozedere mit anderen Parametern genau so durchführen, dann kann man ihn wieder ins Leben holen. Scheint mir aber eher Bug als Feature zu sein...
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.