1
\$\begingroup\$

When running a program on my STM32L432 Nucleo board it runs just fine. I recently created a custom PCB that embeds the same MCU and I use an external STLinkV3 to program it. I am able to connect to the board through the STM32CubeProgrammer and do things like write a hex file and do a chip erase.

When I try to program the board over OpenOCD using VSC, it goes through without any errors, but the board isn't running as intended. When I try to debug, it doesn't stop at my breakpoints and when I pause it, there is no pointer to the current instruction. The log from the gdb-server terminal output looks like

[2023-02-18T06:23:33.400Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
/opt/homebrew/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "/Users/jpwolfe/Documents/VisualStudio/STM32/LCD TFT" -f /Users/jpwolfe/.vscode/extensions/marus25.cortex-debug-1.6.10/support/openocd-helpers.tcl -f openocd.cfg
Open On-Chip Debugger 0.12.0+dev-01078-g85ae73de0 (2023-02-18-04:56)
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 <transport>'.
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 500 kHz
Info : STLINK V3J10M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 0.022385
Error: target voltage may be too low for reliable debugging
Info : [stm32l4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32l4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32l4x.cpu on 50000
Info : Listening on port 50000 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
[stm32l4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x1fff1340 msp: 0x20002c10
Info : device idcode = 0x10016435 (STM32L43/L44xx - Rev Z : 0x1001)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
Info : device idcode = 0x10016435 (STM32L43/L44xx - Rev Z : 0x1001)
Info : RDP level 0 (0xAA)
Info : OTP size is 1024 bytes, base address is 0x1fff7000
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
[stm32l4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff3f36 msp: 0x20002c20
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
[stm32l4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff3f36 msp: 0x20002c20
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
[stm32l4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff3f36 msp: 0x20002c20
Info : Unable to match requested speed 500 kHz, using 200 kHz
Info : Unable to match requested speed 500 kHz, using 200 kHz
[stm32l4x.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff3f36 msp: 0x20002c20
Info : dropped 'gdb' connection
shutdown command invoked
[2023-02-18T06:23:45.444Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed

Disregard the "low voltage", that doesn't seem to be the problem here. The biggest difference from this output versus the one that works is the line xPSR: 0x61000000 pc: 0x1fff1340 msp: 0x20002c10 and all the other xPSR lines. The good output displays the pc as 0800xxxx which points to where the program is in the flash memory. It seems that the debugger is trying to read from 0x1fff1340 which doesn't contain anything useful. Any idea why this is happening?

I downloaded OpenOCD using Homebrew with brew install openocd --HEAD. I was able to run the program with moderate success using STM32CubeIDE just to test. Not sure exactly why.

\$\endgroup\$
8
  • \$\begingroup\$ It seems to be having a lot of comms problems. Why should we disregard the low voltage warning as the programmer needs the voltage rail from the target in order to set the logic levels. I’d be addressing the low voltage issue first. \$\endgroup\$
    – Kartman
    Feb 18, 2023 at 9:17
  • \$\begingroup\$ You do have the MCU supply wired to your debug connector for ST-Link to use that voltage, right? If not, the complain sbout low voltage is spot on! \$\endgroup\$
    – Justme
    Feb 18, 2023 at 9:36
  • \$\begingroup\$ 0x1fff1340 is in the System Memory block - your micro is likely running in its internal bootloader. Do you have the BOOT0 pin tied low? \$\endgroup\$
    – brhans
    Feb 18, 2023 at 13:44
  • \$\begingroup\$ @Kartman I don't think it's that because I can connect to the CubeProgrammer and read and flash code just fine. The communication is working \$\endgroup\$ Feb 18, 2023 at 14:18
  • \$\begingroup\$ @brhans It looks like I left BOOT0 floating. Do you think this is the problem? \$\endgroup\$ Feb 18, 2023 at 14:18

2 Answers 2

1
\$\begingroup\$

When the ST-Link V3 reports Info : Target voltage: 0.022385 Error: target voltage may be too low for reliable debugging this is a problem for sure : the probe adjusts its voltage levels on the debug port to the voltage of the target. If it measures 0.02V, it's not measuring anything real (like 1.8V or 3.3V) and so the debug port levels won't be correct and the probe won't be able to connect. Check that VCC (pin 1) of the probe is correctly wired to your targets VCC.

\$\endgroup\$
0
\$\begingroup\$

Found out that you can also do this with software by setting the option bytes in the CubeProgrammer!

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Can you expand on this a little bit? So that this answer can be useful for someone else. \$\endgroup\$
    – Velvet
    Feb 22, 2023 at 9:10
  • \$\begingroup\$ @Velvel Basically if you leave the BOOT pin floating in hardware, you can still have the MCU always boot from FLASH memory by setting the correct option bytes in the CubeProgrammer so that the MCU always boots from FLASH. Unfortunately this doesn't allow for flexibility because you won't be able to change BOOT modes. \$\endgroup\$ Feb 23, 2023 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.