STMF302 SWO geht nur einmal

Foerch schrieb:
> Was mache ich falsch?

Du beschreibst nicht genau unter welchen Umständen das passiert
und was "einmal" bedeuted. Einmal pro Tag, pro Zeichen, pro
Tastatureingabe, pro Schleifendurchlauf, pro Interrupt, pro was?

Foerch schrieb:
> Funktioniert die Ausgabe jedes mal ein mal dann ist Schluss.

Ich kann mich eimal mit dem STM32 St-link Utily verbinden und es kommt 
dann einmal mein text. aber nicht sequenziell. Es sollte ja die Zahl 
nach test inkrementiert werden. Beim Stm32F103 geht es genau so.

Wie macht Ihr das mit dem SWO beim F302?

Florian P. schrieb:
> Funktioniert denn dein TogglePin? Also wird der IRQ mehrfach
> aufgerufen?
>
> Optimiert der Compiler möglicherweise die while(1) weg und das Programm
> endet einfach? Verleg doch Testweise deine Schleife in die Whileschleife
> im main und mach bevor ich gesteinigt werde nur für den Test eine
> HAL_Delay(500) dahinter.

Das Led Toggelt. Auch wenn ich das Ganze in die While packe ist das 
selbe.
Die Optimierung ist aus.
Habe keine Erklärung.

Foerch schrieb:
> Was mache ich falsch?
> Wie macht Ihr das mit dem SWO beim F302?

Ohne HAL so:
http://stefanfrings.de/stm32/stm32f3.html#traceswo
http://stefanfrings.de/stm32/stm32f3.html#newlib

Ich zitiere aus deinem Code:

1

int _write(int32_t file, uint8_t *ptr, int32_t len)

2

{

3

  /* Implement your write code here, this is used by puts and printf for example */

4

  /* return len; */

5

  int i;

6

  for (i=0;i<len;i++)

7

  {

8

    ITM_SendChar(*ptr++);

9

  }

10

  return len;

11

12

13

  errno = ENOSYS;

14

  return -1;

15

}

Die letzten beiden Zeilen werden nie ausgeführt. War das so gewollt? Auf 
jeden Fall sollte der return-Wert = len sein. Was errno angeht, bin ich 
unsicher.

Stefan ⛄ F. schrieb:
> Foerch schrieb:
>> Was mache ich falsch?
>> Wie macht Ihr das mit dem SWO beim F302?
>
> Ohne HAL so:
> http://stefanfrings.de/stm32/stm32f3.html#traceswo
> http://stefanfrings.de/stm32/stm32f3.html#newlib
>
> Ich zitiere aus deinem Code:int _write(int32_t file, uint8_t *ptr,
> int32_t len)
> {
>   /* Implement your write code here, this is used by puts and printf for
> example */
>   /* return len; */
>   int i;
>   for (i=0;i<len;i++)
>   {
>     ITM_SendChar(*ptr++);
>   }
>   return len;
>
>   errno = ENOSYS;
>   return -1;
> }
>
> Die letzten beiden Zeilen werden nie ausgeführt. War das so gewollt? Auf
> jeden Fall sollte der return-Wert = len sein. Was errno angeht, bin ich
> unsicher.

Hallo das die beiden letzten Zeilen nicht erreicht werden ist mir 
bewusst.
Beim F103 wie bereits erwähnt ist dies kein Problem.

Habe deinen Code aus dem Link ausprobiert.
Das Ergebnis ist das Selbe.
Einmal beim verbinden des St-Link-Utiliy bekomme ich die Hello World 
Ausgabe.

Kann es am Chip liegen? oder was meint ihr?

Was mich sehr stutzig macht ist, dass die Variable i offenbar nicht 
hichgezählt wird. Vielleicht mach der µC einen ungewollten Reset.

Konzentriere dich erst einmal mal darauf.

Ich würde alles auskommentieren, was gerade nicht gebraucht wird (auch 
die 72 MHz) und innerhalb der Hauptschleife die LED blinken lassen und 
Textausgaben machen. Zur Verzögerung (ohne timer!) kannst du die delay 
Schleife von meiner Homepage kopieren.

Erst wenn das läuft, würde ich nach und nach wieder alles 
einkommentieren, bis der Fehler wieder auftritt.

Du kannst dazu ja in der Hauptschleife versus Timer-Interrupt 
unterschiedliche LED's blinken lassen und unterschiedliche Textausgaben 
machen, um diese beiden Codes auseinander halten zu können.

Stefan ⛄ F. schrieb:
> Was mich sehr stutzig macht ist, dass die Variable i offenbar
> nicht
> hichgezählt wird. Vielleicht mach der µC einen ungewollten Reset.
>
> Konzentriere dich erst einmal mal darauf.
>
> Ich würde alles auskommentieren, was gerade nicht gebraucht wird (auch
> die 72 MHz) und innerhalb der Hauptschleife die LED blinken lassen und
> Textausgaben machen. Zur Verzögerung (ohne timer!) kannst du die delay
> Schleife von meiner Homepage kopieren.
>
> Erst wenn das läuft, würde ich nach und nach wieder alles
> einkommentieren, bis der Fehler wieder auftritt.
>
> Du kannst dazu ja in der Hauptschleife versus Timer-Interrupt
> unterschiedliche LED's blinken lassen und unterschiedliche Textausgaben
> machen, um diese beiden Codes auseinander halten zu können.

Hallo,
also der Chip schmiert nicht ab.
Die Led in der Hauptschleife kann ich ansteuern.
Das st_link_Utily macht beim verbinden einen Reset.
Und deshalb ist der Wert immer eins.
Aber es wird nur einmal eine Ausgabe gemacht dann ist Schluss
 Mit dem Debugger kann ich in sehen das jedes mal die ITM_SendChar 
ausgeführt wird.

Ach so, dann hatte ich wohl deine Fehlerbeschreibung missverstanden.

> Die Led in der Hauptschleife kann ich ansteuern.

Was ist mit Textausgaben? Geht dort auch nur eine Zeile? Und wenn du 
beides kombinierst, bekommst du dann eine Zeile aus der Hauptschleife 
und eine aus der ISR, oder was passiert dann?

Hängt die ISR eigentlich, wenn die Ausgabe stoppt? Oder schreibt sie den 
Text ins Nirvana? Da kann man doch prima debuggen.

Mag mir jemand probieren ein Programm zu schreiben das auf dem SWO Port 
was ausgibt?
Dann würde ich dieses bin File hier laden.

Stefan ⛄ F. schrieb:
> Was ist mit Textausgaben? Geht dort auch nur eine Zeile? Und wenn du
> beides kombinierst, bekommst du dann eine Zeile aus der Hauptschleife
> und eine aus der ISR, oder was passiert dann?
>
> Hängt die ISR eigentlich, wenn die Ausgabe stoppt? Oder schreibt sie den
> Text ins Nirvana? Da kann man doch prima debuggen.

Nein in diesem Fall bekomme ich nur eine Zeile aus der Hauptschleife.
Es bleibt nichts hängen wie gesagt mit dem Debugger komme ich bis in die 
ITM_SendChar
Dann landet es im Nirvana:(

Foerch schrieb:
> debug.PNG

In der LogAusgabe steht:
"08:04:24 SWV Reception STOPPED"   .... wer stoppt/startet das?

und weiter oben steht "SWD Frequency 4,0 MHz" in serial Viewer steht 
aber 2000kHz...

Ich kenne die ST-IDE leider nicht, aber meine Kombi aus IAR Workbench 
mit Segger JTrace/JLink reagiert auf SWD Frequenz "missmatches" auch 
gerne mal ungehalten...

VG, Stephan

Stephan schrieb:
> In der LogAusgabe steht:
> "08:04:24 SWV Reception STOPPED"   .... wer stoppt/startet das?

Man kann mit dem Botton in der Gui Starten oder Stopen

Stephan schrieb:
> und weiter oben steht "SWD Frequency 4,0 MHz" in serial Viewer steht
> aber 2000kHz...

Also das eine ist die Geschwindikeit des SWD und das andere ist die 
Geschwindigkeit des SWV die von der Taktfrequenz abhängig ist.

Wenn ich im St-Link-Utily die Frequenz ändere passt sich automatisch die 
Frequenz des SWV an.

Foerch schrieb:
> Mag mir jemand probieren ein Programm zu schreiben das auf dem SWO Port
> was ausgibt?

Siehe Anhang. Die LED hängt an PA5. Taktfrequenz ist 8 MHz (HSI).

Ich habe nur wenige Zeilen zur generierten main.c hinzugefügt:

1

/* USER CODE BEGIN 0 */

2

3

// Output a trace message

4

void ITM_SendString(char *ptr)

5

{

6

    while (*ptr)

7

    {

8

        ITM_SendChar(*ptr);

9

        ptr++;

10

    }

11

}

12

13

/* USER CODE END 0 */

Und:

1

/* USER CODE BEGIN 3 */

2

3

  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);

4

  ITM_SendString("Tick\n");

5

  HAL_Delay(1000);

6

7

  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);

8

  ITM_SendString("Tock\n");

9

  HAL_Delay(1000);

10

11

  }

12

  /* USER CODE END 3 */

Leider ist es mir nicht gelungen, die SWO Meldungen innerhalb der STM32 
Cube IDE anzuzeigen. Ich bin 100% sicher, das das früher mal geklappt 
hatte. Die Ursache für das Problem habe ich nicht gefunden.

Dafür aber einen Workaround: Ich stelle in der "Debug Configuration" 
anstelle von GDB den OpenOCD mit "Configuration script: user defined". 
In der generierten Datei SWO_Test_mit_HAL Debug.cfg füge ich ganz am 
Ende dies ein:

1

tpiu config internal /home/stefan/debug.txt uart off 8000000

2

itm port 0 on

Dadurch bekomme ich SWO Meldungen in die Datei debug.txt geschrieben. 
Das hat geklappt.

Stefan ⛄ F. schrieb:
> Leider ist es mir nicht gelungen, die SWO Meldungen innerhalb der STM32
> Cube IDE anzuzeigen.

Ich habe gerade auf die IDE Version 1.4.0 aktualisiert, jetzt klappt 
auch das.

Stefan ⛄ F. schrieb:
> Siehe Anhang. Die LED hängt an PA5. Taktfrequenz ist 8 MHz (HSI).

Vielen Herzlichen Dank!!!
Habe das SWO_Test_mit_HAL.elf aus deiner Zip in den Chip geladen ohne 
das ich es copiliere.
Das Ergebnis ist aber das selbe :((
Das kann doch nur mehr der Chip sein oder?

Foerch__ schrieb:
> Das Ergebnis ist aber das selbe :((
> Das kann doch nur mehr der Chip sein oder?

Oder die Stromversorgung. Verwendest du dazu ein USB Kabel? Dann geht es 
vielleicht mit einem anderen Kabel besser. Oder einem anderem Port am 
PC.

Stefan ⛄ F. schrieb:
> Oder die Stromversorgung. Verwendest du dazu ein USB Kabel? Dann geht es
> vielleicht mit einem anderen Kabel besser. Oder einem anderem Port am
> PC.

Das Nucleo Port ist neu mit verschiedenen USB Kabeln an 2 Notebooks 
ausprobiert und immer das selbe! Ich werde......:(
Das kann doch nicht sein einen ganzen Tag zu versemmeln....
Ich bin mittlerweile so drauf das ich es einfach wissen muss was das 
Problem ist. Das frisst mich auf.
Kennst du das?

Ich würde an deiner Stelle einfach ein neues Nucleo Board bestellen. So 
teuer sind die ja nicht. Danach hast du Gewissheit.

Die Firmware vom STLink mal aktualisiert?

Jetzt funktioniert es :))))))))


Habe jetzt die Firmware des Nucleoboard auf V2J30M19 upgedatet und siehe 
da damit klappt es. Sei es mit meiner als auch mit deiner Software!!!

Es ist echt aus der Haut zu fahren!!!!
Ein ganzer Tag für sowas!!!!

Danke allen für die Hilfe

Schön, dass wir dir helfen konnten.

Das passiert beim STLink leider häufiger, ich weiß auch nicht warum da 
immer neue Firmware rein muss. Wenn etwas inkompatibel ist, dann sollte 
die Software das wenigstens melden.

OpenOCD hat bei mir immer funktioniert, egal mit welcher Firmware 
Version.

Die Updates nerven. Sie sind ja auch nicht ganz risikofrei.

Johannes S. schrieb:
> Wenn etwas inkompatibel ist, dann sollte
> die Software das wenigstens melden.

Ja das wäre nicht schlecht! Hatte das Nucleo letzte Woche bei Farnell 
bestellt und wollte gestern damit spielen... an ein update hätte ich nie 
und nimmer gedacht. Hatte bereits einige dieser nucleo boards und habe 
da nie bewusst updates gefahren.

Foerch. schrieb:
>> Wenn etwas inkompatibel ist, dann sollte
>> die Software das wenigstens melden.

> Ja das wäre nicht schlecht!

nach dem Upgrade der IDE von 1.3.0 auf 1.4.0 wurde ich von dieser 
aufgefordert, meinen ST-Link (mal wieder) zu aktualisieren. Jetzt frage 
ich mich, ob das Update der IDE oder des ST-Link der entscheidende Punkt 
war.

Moment mal ..... (gut dass ich ein Backup habe) ......

Tatsache! Jetzt klappt die Ausgabe auch bei mir mit der alten IDE 1.3.0.