Nucleo STM32H743 ITM Schnittstelle

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!

War keine externe Hardware dran. Wollte nur mit den LEDs n bissel 
blinkern...

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.

Hast du nähere Infos?

Nur so als Frage:
wie verhält sich das Board mit dem STM32CubeProgrammer?

http://www.st.com/en/development-tools/stm32cubeprog.html

Das probiere ich morgen gleich mal aus

Morgen,

was heisst geht nicht?
Hast du die verschiedenen "Reset Mode" durch probiert?

Auch "Under Reset" und "OB" ?

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 ...

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.