I was trying to run the hello test on Nucleo f446re since there are no instructions for f4 boards, i was referring to this page: 8.2.19. stm32h7 — RTEMS User Manual 7.491f6c8 (12th May 2025) documentation when i run ../../rtems/7/bin/arm-rtems7-gdb build/arm/stm32f4/testsuites/samples/hello.exe , this is the ST-Link gdb server output:
./ST-LINK_gdbserver.sh -cp /Applications/STMicroelectronics/STM32Cube/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/Resources/bin/
STMicroelectronics ST-LINK GDB server. Version 7.11.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Enabled
LogFile Name : debug.log
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
so i think it connects and disconnects immediately? I am using macOS tahoe, is this because of my computer or something entirely different?
I’ve never been able to get the “official” ST gdb shim to work with the RTEMS tool chain. I’ve used openOCD with an ST-Link a while ago, and a J-Link with openOCD, but the ST-Link gdb server hasn’t wanted to talk to arm-rtemsX-gdb.
I didn’t investigate the reason that the ST-Link server didn’t talk. I’d been using openOCD for years before the ST solution came about and openOCD was crunchy, but it just worked.
As for command line debugging, not so much, I use Eclipse (be nice) on a Mac (be nice), and am old enough to have no time for CLI debugging.
So, try openOCD.
For reference, I have had no issue running st-util running on a raspberry pi and being used by the RTEMS automated tester to cycle through the entire testsuite on a STM32H7. I believe the command I was using was st-util --connect-under-reset.
That’s super interesting actually. The F446 has the same guts as the F407, so the whole F4 BSP will just work (other than the lack of memory and redirected serial port). The H7 is more complex, but still a lot like the F4. st-util talks to them all, so if you can get st-util to talk to an H7, that’s interesting (a lot more interesting than going through the open OCD (lack of) documentation).
Oh yes I forgot to update. I tried both openocd and st-util and both seemed to work fine. I tried running programs like blinky and it runs on the board. The only thing I was not able to figure out is to see the serial output.
I think I know what is going on with your serial port. The STM32F4 BSP assumes that you want to use USART3 on pins PD8/PD9.
The Nucleo 446 doesn’t even have a pin PD9, being a small package part. Instead they bring out PA2 and PA3 and connect them to the virtual com port on the ST-Link processor. PA2/3 are on USART2.
So you get to define a variant. See RTEMS 7 stm32f4 console not working - #12 by kiwichris for hints.
Ok I tried with USART2 enabled but still the same thing. When i checked the registers in gdb this is the out put:
usart_write_polled (minor=0, c=13 '\r') at ../../../bsps/arm/stm32f4/console/usart.c:232
232 while ((usart->sr & STM32F4_USART_SR_TXE) == 0) {
(gdb) set $RCC = 0x40023800
(gdb) p/x *(uint32_t*)($RCC + 0x40)
$4 = 0x0
(gdb) p/x (*(uint32_t*)($RCC + 0x40)) & 0x00020000
$5 = 0x0
(gdb) set $U2 = 0x40004400
(gdb) x/6wx $U2
0x40004400: 0x00000000 0x00000000 0x00000000 0x00000000
0x40004410: 0x00000000 0x00000000
What I understood here is it is not enabled?
Also I tried changing register values via gdb to expected states, still no use.