mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Nucleo STM32H743 ITM Schnittstelle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Schorsch X. (bastelschorsch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe B. (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ewqtrwetqrwrtwq (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das hat beim F7 schon nicht sauber funktioniert ...

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

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mts (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War keine externe Hardware dran. Wollte nur mit den LEDs n bissel 
blinkern...

Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du nähere Infos?

Autor: pegel (Gast)
Datum:

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

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

Autor: Ingo Less (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das probiere ich morgen gleich mal aus

Autor: Ingo L. (corrtexx)
Datum:

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

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen,

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

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch "Under Reset" und "OB" ?

Autor: Ingo L. (corrtexx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ingo L. (corrtexx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.