Unable to debug/STLink to STM32MP157C-DK1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-18 02:58 PM
New to STM32CubeIDE and trying to compile/download examples to STM32MP157C-DK1.
It seems that the ST-Link on this particular board is not functioning correctly, both STM32CubeProgrammer and command line suggest that there is 'No device found on target'.
C:\Windows\System32>C:\ST\STM32CubeIDE_1.16.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.win32_2.1.400.202404281720\tools\bin\ST-LINK_gdbserver.exe -p 61234 -l 1 -d -s -cp C:\ST\STM32CubeIDE_1.16.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.400.202404281720\tools\bin -m 2 -g
STMicroelectronics ST-LINK GDB server. Version 7.8.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Target no device found
Error in initializing ST-LINK device.
Reason: No device found on target.
However if I connect with ST-Link in OpenOCD mode it shows that there is a processor (two indeed!). If I try to debug with this connection I get a host of other weird errors...
I have flashed the ST-Link to the newest version 'V2.J45.M31'.
I can connect successfully to another ST-Link capable dev-board (ST-USB02).
Any suggestions?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-21 09:53 AM
@PatrickF wrote:STLINK port is only for debugging (and providing console UART thru VCP).
Are you saying that it is NOT POSSIBLE to debug the cores running on the STM32MP1 (via ST-Link or OpenOCD)? By that I mean set break points, inspect memory and registers....
No, sorry if my sentence was misleading, debug is totally possible and you should try it using this step by step approach with CubeIDE :Develop on Arm Cortex-M4/Modify, rebuild and reload a firmware
I cannot comment your trials with OpenOCD, but I think when Linux is running you likely cannot stop the Cortex-A7 (debug not allowed unless enabled, see https://wiki.st.com/stm32mpu/wiki/Debugging_the_Linux_kernel_using_the_GDB).
For the Cortex-M4, debug is enabled with Starter Package as described in the wiki Develop on Arm Cortex-M4/Modify, rebuild and reload a firmware
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-20 11:17 PM
Hi @SDW
for STM32MP series, CubeProgrammer is only usable thru USB (or UART in some extend).
STLINK port is only for debugging (and providing console UART thru VCP).
Note that depending on BOOT pins or SW running, debugging might be disabled.
If you are trying to debug Cortex-M4 FW with CubeIDE, you need either to have
- an up and running Linux (aka "production mode")
- or BOOT pins set to Development Boot.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-21 09:20 AM
Hi @PatrickF
I was able to use USB/DFU mode to download a pre-build Linux image/environment ('FlashLayout_sdcard_stm32mp157a-dk1-optee.tsv') to the board and access the console via the micro-B connector. However that is not what I am asking.
@PatrickF wrote:STLINK port is only for debugging (and providing console UART thru VCP).
Are you saying that it is NOT POSSIBLE to debug the cores running on the STM32MP1 (via ST-Link or OpenOCD)? By that I mean set break points, inspect memory and registers....
It seems that the ST32CubeIDE is configured for just that, see attached. Is this a limitation of the the DK1/DK2 dev boards, or of the processor as a whole (seems very unlikely)?
Our expectation/task was to evaluate running custom code on the Cortex-M4 and understand how to configure/use it's SPI/I2C through the pins of the STM32MP1. Eventually we are hoping that this code could run along side a Linux environment running on the Cortex-A7 cores, on a custom PCB.
Is there some documentation on how to build/install the examples from:
https://github.com/STMicroelectronics/STM32CubeMP1
The readme is not that clear. Do they need to be imported into the Linux image/DFU and then that download as a whole?
BTW I already discovered that the examples don't build with the latest tool chain, I installed an older one which does appear to work (well build at least).
Thanks, Simon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-21 09:53 AM
@PatrickF wrote:STLINK port is only for debugging (and providing console UART thru VCP).
Are you saying that it is NOT POSSIBLE to debug the cores running on the STM32MP1 (via ST-Link or OpenOCD)? By that I mean set break points, inspect memory and registers....
No, sorry if my sentence was misleading, debug is totally possible and you should try it using this step by step approach with CubeIDE :Develop on Arm Cortex-M4/Modify, rebuild and reload a firmware
I cannot comment your trials with OpenOCD, but I think when Linux is running you likely cannot stop the Cortex-A7 (debug not allowed unless enabled, see https://wiki.st.com/stm32mpu/wiki/Debugging_the_Linux_kernel_using_the_GDB).
For the Cortex-M4, debug is enabled with Starter Package as described in the wiki Develop on Arm Cortex-M4/Modify, rebuild and reload a firmware
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-10-22 09:36 AM
Hi @PatrickF
Thank you for the links, after connecting an ethernet cable I was able to build and download the example code to board, whilst it was running the pre-built Linux environment.
I was not able to set breakpoint (well could set, but they would skip) early in 'main()', but it's mentioned that debugger runs the '.elf' file and then attaches to (the already running) process.... not a huge problem.
Now to test a few more examples and figure out the various HAL/etc layers.
Thanks, Simon.