Nucleo STM32H743 ITM Schnittstelle

[Schorsch X. (bastelschorsch)]

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

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

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

[ewqtrwetqrwrtwq (Gast)]

das hat beim F7 schon nicht sauber funktioniert ...

lösung lief immer über den AXI mit cache ...

[Ingo Less (Gast)]

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

[mts (Gast)]

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 (Gast)]

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

[A. B. (Gast)]

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.

[Ingo Less (Gast)]

Hast du nähere Infos?

[pegel (Gast)]

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

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

[Ingo Less (Gast)]

Das probiere ich morgen gleich mal aus

[Ingo L. (corrtexx)]

Keine Chance, geht auch damit nicht... Weitere Rettungsvorschläge?

[pegel (Gast)]

Morgen,

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

[pegel (Gast)]

Auch "Under Reset" und "OB" ?

[Ingo L. (corrtexx)]

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

[Ingo L. (corrtexx)]

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

[pegel (Gast)]

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.

[A. B. (Gast)]

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. (corrtexx)]

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

[A. B. (Gast)]

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.

[Ingo L. (corrtexx)]

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