STM32CubeIDE - kann man dem gdb server einen Schalter mitgeben?

[Christoph K. (chriskuku)]

Ich möchte - experimentweise - dem gdbserver den Schalter

set mem inaccessible-by-default off

(den man normalerweie ins .gdbinit schreiben kann) - mitgeben. Geht das, 
z.B. über die Commandline?

[Klaus W. (mfgkw)]

Der gdbserver läuft auch nicht Lokal auf deinem Rechner, sondern auf dem 
Target.
Was ist dein Target? Wenn es ein PC ist, kannst du ihm das mitgeben was 
der gdbserver dort an Argumenten kennt.
Wenn irgendwo etwas implizit eingebaut ist, was gdbserver-Protokoll 
implementiert (stlink bspw. für STM32), dann musst du dort in der Doku 
schauen.

[Klaus W. (mfgkw)]

Alles zurück!
Dein Kommando ist doch gar nicht für den gdbserver, sondern für den 
gdb...

[J. S. (jojos)]

Debug Configurations (Pfeil am Käfersymbol) - Startup Tab - in Init oder 
Run commands eintragen

[Bauform B. (bauformb)]

Christoph K. schrieb:
> set mem inaccessible-by-default off

Kann man das eigentlich auch genauer einstellen? Also indem man 
bestimmte Adressbereiche für gültig erklärt, z.B. für das RAM 0x20000000 
.. 0x20001fff bis hin zu mehreren Bereichen für verschiedene I/O-Module.

Der Anlass: ein Tippfehler im Linkerscript und schon überschreibt mir 
der gdb mein internes EEPROM.

[Christoph K. (chriskuku)]

Klaus W. schrieb:
> Der gdbserver läuft auch nicht Lokal auf deinem Rechner, sondern auf dem
> Target.
> Was ist dein Target? Wenn es ein PC ist, kannst du ihm das mitgeben was
> der gdbserver dort an Argumenten kennt.
> Wenn irgendwo etwas implizit eingebaut ist, was gdbserver-Protokoll
> implementiert (stlink bspw. für STM32), dann musst du dort in der Doku
> schauen.

Mein Target ist STLINK-V2 im DISC1 Board (momentan mit der on Board 
MCU).

[Christoph K. (chriskuku)]

J. S. schrieb:
> Debug Configurations (Pfeil am Käfersymbol) - Startup Tab - in Init oder
> Run commands eintragen

Danke. Habe es so als Kommando SET... in das Initialization Commands 
Feld eingetragen. Sehe zwar keine Fehlermeldung, aber auch keine 
Wirkung.

Seit kurzem kriege ich nämlich immer ein TRACE trap. Zugriff auf Adresse 
(00000000) außerhalb des Programmbereichs, und zwar habe ich jetzt 
festgestellt, daß es am memmap file (Loader map) liegt:

MEMORY
{
        FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
        FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
        CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
        SRAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
        .text   : {
                    flashend = 0x00100000 ;
                    ccmbgn   = 0x10000000 ;
                    ccmend   = 0x10010000 ;
                    srambgn  = 0x20000000 ;
                    sramend  = 0x20020000 ;
                    *(.text)
                  } > FLASH_ALIAS AT > FLASH
        .bss    : { *(.bss)  } > CCMRAM
        .sram   : { *(.sram) } > SRAM
}

Benutze ich den hier, :

MEMORY
{
        FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
        CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
        SRAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
        .text   : {
                    flashend = 0x00100000 ;
                    ccmbgn   = 0x10000000 ;
                    ccmend   = 0x10010000 ;
                    srambgn  = 0x20000000 ;
                    sramend  = 0x20020000 ;
                    *(.text)
                  } > FLASH
        .bss    : { *(.bss)  } > CCMRAM
        .sram   : { *(.sram) } > SRAM
}

dann tritt das Problem nicht auf.


EDIT: Kommando zurück. Problem tritt auch im letzteren Fall auf. Liegt 
also nicht an der Loader map. Das Programm läuft nicht auf die 
Einsprungadresse "Reset".

[Bauform B. (bauformb)]

Christoph K. schrieb:
> FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K

Ist das nützlich? Nach einem Hardware-Reset geht es bei 0x0800'0000 los.

Zur Sache: Es geht um eine Assembler-Programm auf einem F405/407 oder? 
Dabei muss man mit dem Stack-Alignment aufpassen. ARM möchte 8 Byte, das 
müsste man bei jeder Funktion berücksichtigen. Man darf dann z.B. 
Register nur paarweise pushen, ggf. eins unnötigerweise.

Die Einstellung 4-Byte vs. 8-Byte passiert mit STKALIGN im SCB->CCR. 
Default nach Reset ist wahrscheinlich 8. Bei neueren Chips ist das Bit 
read-only auf 8 eingestellt.


> Habe es so als Kommando SET... in das Initialization Commands
> Feld eingetragen. Sehe zwar keine Fehlermeldung, aber auch keine
> Wirkung.

Probier mal "print /x *0x40000000", das müsste je nach Einstellung 
Mecker geben oder nicht.

[Christoph K. (chriskuku)]

Bauform B. schrieb:
> Christoph K. schrieb:
>> FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
>
> Ist das nützlich? Nach einem Hardware-Reset geht es bei 0x0800'0000 los.
>

Ich brauche das Programm (später, nicht unbedingt dieses kleine 
Testprogramm) gelinkt auf 0x00000000, weil die Adressen zu 16bit Token 
werden.

> Zur Sache: Es geht um eine Assembler-Programm auf einem F405/407 oder?

Ja, F407.

> Dabei muss man mit dem Stack-Alignment aufpassen. ARM möchte 8 Byte, das
> müsste man bei jeder Funktion berücksichtigen. Man darf dann z.B.
> Register nur paarweise pushen, ggf. eins unnötigerweise.

Frage: Wenn zu Anfang der Stack richtig aligned ist und ich pushe nur
ein Register (32bit) , dann wird der SP um 4 decrementiert. Und das soll 
dann ein Fehlalignment sein? Dann müßte es ja überall krachen?

Ich finde im Moment das SCB nicht im RM0090 um mal nachzugucken, was die 
Resetwerte sind.

>
> Die Einstellung 4-Byte vs. 8-Byte passiert mit STKALIGN im SCB->CCR.
> Default nach Reset ist wahrscheinlich 8. Bei neueren Chips ist das Bit
> read-only auf 8 eingestellt.
>
>
>> Habe es so als Kommando SET... in das Initialization Commands
>> Feld eingetragen. Sehe zwar keine Fehlermeldung, aber auch keine
>> Wirkung.
>
> Probier mal "print /x *0x40000000", das müsste je nach Einstellung
> Mecker geben oder nicht.

Keine Wirkung, mit oder ohne "set mem inaccessible-by-default off"
print /x *0x40000000
$2 = 0x0

[Bauform B. (bauformb)]

Christoph K. schrieb:
> Ich finde im Moment das SCB nicht im RM0090 um mal nachzugucken, was die
> Resetwerte sind.

Das ist im Programming Manual versteckt, PM0214 sollte passen.

[Bauform B. (bauformb)]

Christoph K. schrieb:
> Frage: Wenn zu Anfang der Stack richtig aligned ist und ich pushe nur
> ein Register (32bit) , dann wird der SP um 4 decrementiert. Und das soll
> dann ein Fehlalignment sein? Dann müßte es ja überall krachen?

Keine Ahnung, wann genau es dann kracht, evt. erst bei einem 
Interrupt. Eine kurze/schnelle Funktion, die nur 1 Register pusht und 
poppt, würde dabei sehr selten zum Crash führen.

Aber evt. steht das STKALIGN Bit auch auf 4 und es passiert ein ganz 
anderer Fehler.

[Christoph K. (chriskuku)]

Bauform B. schrieb:
> Christoph K. schrieb:
>> Frage: Wenn zu Anfang der Stack richtig aligned ist und ich pushe nur
>> ein Register (32bit) , dann wird der SP um 4 decrementiert. Und das soll
>> dann ein Fehlalignment sein? Dann müßte es ja überall krachen?
>
> Keine Ahnung, wann genau es dann kracht, evt. erst bei einem
> Interrupt. Eine kurze/schnelle Funktion, die nur 1 Register pusht und
> poppt, würde dabei sehr selten zum Crash führen.
>
> Aber evt. steht das STKALIGN Bit auch auf 4 und es passiert ein ganz
> anderer Fehler.

Wenn ich schrittweise durch die SetupClocks und SetupUART Routinen 
durchsteppe, läuft das Programm (abgesehen davon, daß noch nichts aus 
dem UART rauskommt). Setze ich einen Breakpoint hinter SetupUART, gibt 
es diesen

 Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()

Wie kann ich ein komplettes STM32CubeIDE Projekt hier hochladen? Oder 
genügt Source alleine. Ist ja Assembler, also keine sonstigen Libraries. 
Nur ein Makefile.

STKALIGN wird nicht berührt, steht also auf 1 (Reset Value)

[Bauform B. (bauformb)]

Also, im Moment glaube ich, dass das unmöglich laufen kann. Bei 168MHz 
braucht der Flash-Speicher mindestens 5 wait states und die 
Taktumschaltung besteht aus mehreren Schritten in der richtigen 
Reihenfolge (RM0090 -> Embedded Flash memory interface -> Read 
Interface). Davon sehe ich in deinem Programm nicht viel.

Am einfachsten wäre es, wenn du den Takt vorläufig beim HSI lässt. Sonst 
gibt es so viele zusätzliche und unnötige Fehlerquellen. Immer eins nach 
dem anderen...

Dass es im single step funktioniert, könnte daran liegen, dass du von 
Hand ja ein paar Millionen wait states einfügst. Die CPU ist ja schnell 
genug, nur der Speicher nicht.

Christoph K. schrieb:
> Wie kann ich ein komplettes STM32CubeIDE Projekt hier hochladen? Oder
> genügt Source alleine. Ist ja Assembler, also keine sonstigen Libraries.
> Nur ein Makefile.

Source und Makefile müssen reichen. Wenn es damit nicht läuft, geht's 
mit CubeMX erst recht nicht. Wenn es reines C wäre, mag das anders 
aussehen.

[Christoph K. (chriskuku)]

Hatte die FLASH Parameter Section vergessen hinzuzufügen. Noch mal eine 
aktualisierte Version. Der TRAP 0 ist jetzt weg. Bei der USARTDIV 
Berechnung bin ich mir nicht ganz sicher. Die PCLK1 is 42MHz. Daraus 
berechne ich (OVER8=0) 22.78 => 0x016c als USART_BRR Wert.

[Bauform B. (bauformb)]

Christoph K. schrieb:
> Bei der USARTDIV Berechnung bin ich mir nicht ganz sicher.
> Die PCLK1 is 42MHz. Daraus berechne ich (OVER8=0) 22.78 => 0x016c
> als USART_BRR Wert.

Die Berechnung ist eigentlich einfacher, die 16 für den fractional Teil 
kürzt sich raus. Dann bleibt: UART_BRR = fck / baud
Oder etwas genauer, weil gerundet: UART_BRR = (fck + baud/2) / baud
Noch einfacher wird's, wenn man nicht auf Hex umrechnet ;)

Bei fck hätte ich mehr Zweifel. Ist der wirklich gleich PCLK1? Ist PCLK1 
wirklich HCLK/4? Ist 42 auch hier die Antwort?


Christoph K. schrieb:
> FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
> Ich brauche das Programm (später, nicht unbedingt dieses kleine
> Testprogramm) gelinkt auf 0x00000000, weil die Adressen zu 16bit Token
> werden.

Muss für Forth nicht wenigstens ein Teil im RAM liegen? Da wären die 
Token "nur" ein Offset zu 0x20000000 (oder aber 32 Bit breit). Schau dir 
mal die diversen Maschinenbefehlen an, was mit Basis-Register plus 
Offset möglich ist. Viel ist das nicht, die Entfernungen zwischen 0x0, 
Flash und RAM sind alle zu groß für schön einfache Befehle. Deshalb 
lohnt es sich vielleicht kaum, alles nach 0x0 zu linken.

[Christoph K. (chriskuku)]

Bauform B. schrieb:
...
 Christoph K. schrieb:
>> FLASH_ALIAS (rx)  : ORIGIN = 0x00000000, LENGTH = 1024K
>> Ich brauche das Programm (später, nicht unbedingt dieses kleine
>> Testprogramm) gelinkt auf 0x00000000, weil die Adressen zu 16bit Token
>> werden.
>
> Muss für Forth nicht wenigstens ein Teil im RAM liegen? Da wären die
> Token "nur" ein Offset zu 0x20000000 (oder aber 32 Bit breit). Schau dir
> mal die diversen Maschinenbefehlen an, was mit Basis-Register plus
> Offset möglich ist. Viel ist das nicht, die Entfernungen zwischen 0x0,
> Flash und RAM sind alle zu groß für schön einfache Befehle. Deshalb
> lohnt es sich vielleicht kaum, alles nach 0x0 zu linken.

Ein großer Teil sind vorkompilierte FORTH Programmteile, die ins Flash 
programmiert werden. Dazu gehört auch der Interpreter. Die "Tokens" sind 
in mir vorliegenden Implementierung so konstruiert, daß die Bits 3-15 
der Offset sind, mit dem die Codeadresse ermittelt wird. Dann gibt es 
ein RAM-Flag, was besagt, daß das Token aus der RAM-Table zu nehmen 
sind. Ein weiteres Bit sagt, daß es sich um eine Primitive handelt. Der 
FORTH-Code ist "headerless", es werden also nicht mehr die Namen der 
FORTH-Worte mitgeschleppt. Spart Platz, macht das Debuggen aber 
schwierig. Lade derzeit die Symboltabelle mit ins System und kann das 
Programm über SWV/ITM Messages tracen. Das System läuft auch bereits im 
DISC1. Ich versuche es auf dieses DIYMORE-Board zu portieren, wobei ich 
es auch erstmalig unter dem Debugger (STM32CubeIDE) laufen lasse. 
Irgendetwas ist anders am DIYMORE, weshalb es derzeit hakt.

Zu der Clock: Es gilt das, was im Assemblerbeispiel gemacht wird:

HPRE=0000 -> /1
HCLK=SYSCLK
PPRE1=5 -> PCLK1=HCLK/4
PPRE2=4 -> PCLK2=HCLK/2

Immer unter der Voraussetzung, ich hab mich nicht vertan. :)

Anm.: der Vorteil, es nach 0 zu linken, ist, daß die Symbole nicht die 
0x08000000 mitschleppen müssen und man dann eben mit 16bit Offsets 
arbeiten kann. Limitiert zwar die Zahl der FORTH Worte bei dieser 
Implementierung auf 8192, aber das ist für die Anwendung vollkommen 
ausreichend.

[Bauform B. (bauformb)]

Cool, danke!

[Christoph K. (chriskuku)]

Mein Assemblerprogramm in der UARTinitialisierung steckte noch voller 
Fehler. Die Definitionen der Register waren Offsets und ich hatte die 
RCC Base Adresse vergessen. Die Annahmen zur Peripheral Clock waren 
richtig (42MHz) und nach Schreiben des richtigen USARTDIV (42000000 / 
115200 = 364,5833 ~ 365) kam dann auch endlich ein Zeichen ('X') aus dem 
UART.

  ldr r1, = USART3_BRR
  mov r0, #0
  movw r0, #365
  str r0, [r1]

Angehängt habe ich auch die Aufzeichnung des "Glitches". Was ist das 
nun? Ein "Idle"-Frame?

[Bauform B. (bauformb)]

Das sieht ja wie ein echtes Startbit aus. Du triggerst auf die negative 
Flanke und der Cursor steht genau auf der positiven Flanke? Wieviel µs 
sind das, wirklich genau ein Bit @115200 oder Zufall oder ist das Signal 
schon vor T=0 low?

Ein idle frame mit Startbit ist ein schwarzer Schimmel. Aber bei STM 
weiß man ja nie...
Änder mal die Reihenfolge der Initialisierung, die "ruhigste" Methode 
stelle ich mir ungefähr so vor:

@ Turn on the clock for USART3
@ Set PORTB pin 10 High -> BSR := B10
@ Set PORTB pin 10 in output mode
@ Enable the USART
@ fCLK 42MHz, 115200 baud -> BRR := 365
@ Enable the TX, and RX circuit
@ Set alternate function 1 to enable USART3 pins on Port B
@ Set PORTB pins 10 and 11 in alternate function mode

[Christoph K. (chriskuku)]

Danke, @bauformb, für den Vorschlag. Wollte mich schon drangeben, als 
ich feststellte, daß die Glitches jetzt, mit der Version, die ich 
angehängt habe (168MHz, 42MHz PCLK1, 115200 Bd) verschwunden sind.
macOS, Terminalprogramm pico, bluepill UART)

picocom v3.1

port is        : /dev/cu.usbmodemE1CBBADB1
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : crcrlf,lfcrlf,
omap is        : crlf,delbs,
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
XXX

--
Grüße
Christoph