apollolabsdev / stm32-nucleo-f401re Goto Github PK

cargo runworks, but when I start a Debugging Session in vscode with configuration Debug(OpenOCD) :

Launching gdb-server: openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /Users/abc/Work/github/stm32-nucleo-f401re/Polling/gpio -f /Users/abc/.vscode/extensions/marus25.cortex-debug-1.6.5/support/openocd-helpers.tcl -f interface/stlink.cfg -f target/stm32f4x.cfg
Please check TERMINAL tab (gdb-server) for output from openocd
OpenOCD: GDB Server Quit Unexpectedly. See gdb-server output in TERMINAL tab for more details.

In the Terminal I see:

[2022-09-21T15:28:24.046Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /Users/abc/Work/github/stm32-nucleo-f401re/Polling/gpio -f /Users/abc/.vscode/extensions/marus25.cortex-debug-1.6.5/support/openocd-helpers.tcl -f interface/stlink.cfg -f target/stm32f4x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 2000 kHz

[2022-09-21T15:28:24.087Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

Did I miss something to set port 50000 to 3333 ? But where ?

https://github.com/apollolabsdev/stm32-nucleo-f401re/blob/c586a50d609aa8c1d90e113277d4e5bb99ae81d6/PAC%20Examples/sys_clocks/src/main.rs#L18C45-L18C45

Isn't this ready signal bit going to be 0 initially, in which case the busy-wait won't run and execution will pass straight to the next line (without the clock being ready), or the clock will be ready, in which case the while test will evaluate to 1, in which case it will get stuck in the busy-wait forever?

The problem with rust crates is really a headache. Many times I don’t know which foreign version to choose. I completely cloned the project and then this error appeared.

Updating to the latest embassy crates broke the example. It needs to be updated to reflect the latest interfaces.