SWV auf Assembler Level ansprechen

[Christoph K. (chriskuku)]

Ich wollte ein Stück Software, das in Assembler vorliegt, tracen, 
möglichst über SWO, also Nachrichten im SWV-View des STM32CubeIDE.
Aus einem C-Beispielprogramm heraus lief es ja zuletzt. Die 
Tracefunktion ITM_SendChar(char); ist aber ein Stück aus einer 
C-Bibliothek, die dazugelinkt wird.
Die habe ich ja in Assembler nicht. Ich kann vielleicht ein bißchen 
Assemblercode noch dazupacken, der vielleicht das SWV-Protokoll 
implementiert, aber wo und wie?

[A. B. (Gast)]

Also wirklich, das

__STATIC_INLINE uint32_t ITM_SendChar (uint32_t ch)
{
  if (((ITM->TCR & ITM_TCR_ITMENA_Msk) != 0UL) &&      /* ITM enabled */
      ((ITM->TER & 1UL               ) != 0UL)   )     /* ITM Port #0 
enabled */
  {
    while (ITM->PORT[0U].u32 == 0UL)
    {
      __NOP();
    }
    ITM->PORT[0U].u8 = (uint8_t)ch;
  }
  return (ch);
}

in Assembler zu schreiben, kann doch wohl kein Problem sein, oder? Im 
Prinzip ist das doch nur ein UART (zumindest die übliche Einstellung), 
man schreibt das Byte ins Sende-FIFO, wenn Platz ist. Die Abfrage, ob 
"ITM enabled", kann man sich ja auch ggf. noch sparen.

Für z. B. STM32H750 im RM0433, 60.6.3, ITM stimulus register 0, da ist 
die FIFO-Behandlung erklärt.

Der kompliziertere Teil sind die ganzen Einstellungen davor.

[Bauform B. (bauformb)]

Christoph K. schrieb:
> ITM_SendChar(char); ist aber ein Stück aus einer C-Bibliothek,
> die dazugelinkt wird. Die habe ich ja in Assembler nicht.

Hast du ein Programm, in dem ITM_SendChar() in C funktioniert und in 
dem dein Stück Assembler auch drin ist? Dann könnte es mit 3 Zeilen 
Assembler funktionieren:

   .global  ITM_SendChar
   movs r0, #72
   bl   ITM_SendChar

72 ist der Anfang von "Hallo, Welt" ;)

[Christoph K. (chriskuku)]

Bauform B. schrieb:
> Christoph K. schrieb:
>> ITM_SendChar(char); ist aber ein Stück aus einer C-Bibliothek,
>> die dazugelinkt wird. Die habe ich ja in Assembler nicht.
>
> Hast du ein Programm, in dem ITM_SendChar() in C funktioniert und in
> dem dein Stück Assembler auch drin ist? Dann könnte es mit 3 Zeilen
> Assembler funktionieren:
>

   .global  ITM_SendChar
>    movs r0, #72
>    bl   ITM_SendChar

> 72 ist der Anfang von "Hallo, Welt" ;)

Nein, die Konstellation liegt so nicht vor. Ich muß die 
C-Implementierung in Assemblercode einbinden.
Aber ich werde mich mal an das von A.B.(gast) Vorgeschlagene begeben.

[Christoph K. (chriskuku)]

Konnte jetzt ITM_SendString und ITM_SendChar in Assembler 
implementieren:

      .equ ITM             ,   0xE0000000
main:
       ldr r0,=hello
       bl ITM_SendString
       pop {r0,r1}
       b .
hello: .asciz "hi!"
.global ITM_SendChar,ITM_SendString

ITM_SendString:   @  r0 - address of null-terminated String
  push {r0-r1}
        mov r1,r0
1:  mov r0,#0
  ldrb r0,[r1]
  cbz r0,2f
  bl ITM_SendChar
  add r1,#1
  b 1b
2:  pop {r0-r1}
  bx lr  
putchar:
ITM_SendChar:
  push {r0-r1}
1:  ldr r1, = ITM
  ldr r1,[r1]
  cmp r1,#0
  beq 1b
  ldr r1, = ITM
  str r0,[r1]
  pop {r0-r1}
  bx lr

Aber der Debugger (STM32CubeIDE) verhält sich merkwürdig.
Es wird "hi!" in der SWV ITM Console ausgegeben, aber wenn ich durch 
ITM_SendSTring durchsteppe, findet die loop auch die terminierende 0, 
fällt durch auf Label 2: und steppe ich bis zum bx lr springt der 
Debugger zurück auf  `add r1,#1` (!?).

Auch seltsam sind die vielen (sehr vielen) blauen trace-messages Zeile 
590 in simple.s im Debug Window.
Modifiziere ich den Code etwas, so springt der Debugger auf die 
branch-Instruction zurück.

      .equ ITM             ,   0xE0000000
main:
       ldr r0,=hello
       bl ITM_SendString
       pop {r0,r1}
       b .
hello: .asciz "hi!"
.global ITM_SendChar,ITM_SendString

ITM_SendString:   @  r0 - address of null-terminated String
  push {r0-r1}
        mov r1,r0
1:  mov r0,#0
  ldrb r0,[r1],#1
  cbz r0,2f
  bl ITM_SendChar
  b 1b @ <<<<<<<<<\ 
2:  pop {r0-r1} @ | erratischer Rücksprung des Debuggers nach dem bx lr
  bx lr @ >>>>>>>/
putchar:
ITM_SendChar:
  push {r0-r1}
1:  ldr r1, = ITM
  ldr r1,[r1]
  cmp r1,#0
  beq 1b
  ldr r1, = ITM
  str r0,[r1]
  pop {r0-r1}
  bx lr

[Bauform B. (bauformb)]

Kann es sein, dass du gerade die falschen Register rettest? Bei r0 
sollte klar sein, dass du das nicht retten musst. r1 bis r3 darfst du 
bei Bedarf auch "zerstören". Umgekehrt benutzt du das lr um 
ITM_SendChar() aufzurufen, aber das wird noch für die Rückkehr nach main 
gebraucht, sollte also gerettet werden.

Ganz nebenbei finde ich den Namen putchar schöner als ITM_SendChar. Bei 
letzterem denke ich, dass das eine CubeMX-Funktion ist.

[Christoph K. (chriskuku)]

Bauform B. schrieb:
> Kann es sein, dass du gerade die falschen Register rettest? Bei r0
> sollte klar sein, dass du das nicht retten musst. r1 bis r3 darfst du
> bei Bedarf auch "zerstören". Umgekehrt benutzt du das lr um
> ITM_SendChar() aufzurufen, aber das wird noch für die Rückkehr nach main
> gebraucht, sollte also gerettet werden.
>
> Ganz nebenbei finde ich den Namen putchar schöner als ITM_SendChar. Bei
> letzterem denke ich, dass das eine CubeMX-Funktion ist.

Danke. Wertvoller Tipp. Ja klar, bei geschachtelten Subroutine Aufrufen 
muß man eingangs in der SR push {...,rl} und den return mit pop {...,pc}
machen. ARM hat ja keine "RET" Instruction, mit der die Returnadresse 
vom Stack geholt wird. Bereinige das gerade, aber Auprobieren kann ich 
es erst nach dem Fußballspiel.

Und ITM_SendChar wird durch putchar ersetzt. Hatte ich ja schon 
vorgesehen.