2024-07-03 04:48 AM
This fault has appeared very abruptly. One hour ago I was working with the board just fine, programming via STM32CubeIDE. Then I swapped the board to a different USB port on my laptop, now it is not programmable.
When I hit the 'Run' button, it appears to be working, but then fails. The output is below:
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 : 61238
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...
-------------------------------------------------------------------
STM32CubeProgrammer v2.17.0
-------------------------------------------------------------------
Log output file: C:\Users\tcarney\AppData\Local\Temp\STM32CubeProgrammer_a21416.log
ST-Link Server is running on port : 7184
ST-LINK SN : 004D00453532511331333430
ST-LINK FW : V3J15M6
Board : NUCLEO-H755ZI-Q
Voltage : 3.31V
SWD freq : 8000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x450
Revision ID : Rev V
Device name : STM32H7xx
Flash size : 2 MBytes (default)
Device type : MCU
Device CPU : Cortex-M7/M4
BL Version : 0x0
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a21416.srec
File : ST-LINK_GDB_server_a21416.srec
Size : 41.41 KB
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:01.061
Verifying ...
Download verified successfully
Target no device found
Failed to restart ST-LINK connection
Failed to read DAP register for AP 3
Failed to read ROM table via AP 3
Failed to reinitialize device
Shutting down...
Exit.
As you can see, it looks as though it did program, but then failed to restart. I know that it is not working because I am monitoring the UART for expected output but nothing is coming out.
If I try to 'Run' again, I get
If I connect BT0 to VDD I can then connect to the board using STM32CubeProgrammer and do a full chip erase, but this just gets me back into the state where I started from. If I try to program the device from within STM32CubeProgrammer, I get this:
Once again, it seems to be programming, and then failing on restart.
I have updated to v1.16.0 of the IDE, and V3.J15.M6 of the STLink firmware, but nothing changes.
Can anyone offer any insight into what is happening or how I might fix it?
Thanks
2024-08-05 03:47 AM
Hi @TomC1 ,
Any sign of life if you use STM32CubeProgrammer as standalone tool? Try to connect & erase flash content using this tool then come back to STM32CubeIDE.
-Amel
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-08-05 04:10 AM - edited 2024-08-05 04:47 AM
You can connect to the board via CubeProgrammer - so the ST-Link is OK.
The programmer can program the chip and successfully verify what it wrote - so the chip is being programmed correctly.
When your program starts running, the board stops responding - so it looks like your program is doing something wrong.
Create the most basic "blink LED" application and download that to the device. Does it work? then something is definitely wrong with your current application - start debugging from there.
2024-08-05 04:21 AM - edited 2024-08-05 04:23 AM
Updating the st-link will not help here - you have to "update" your program !
Obviously st-link and cpu working fine - until they get your program. :)
as Berry wrote :
>
The programmer can program the chip and successfully verify what it wrote - so the chip is being programmed correctly.
When your program starts running, the board stops responding - so it looks like your program is doing something wrong.
<
Did you set in Cube : using debug or swd ? Do this.
Doing anything on the pins for debug ? Dont do this.
Set correct speed/smps setting (core voltage) ? check.
Or make the simple basic "blink LED" application , with debug set and correct smps/core voltage+speed .
2024-08-05 04:50 AM - edited 2024-08-05 05:53 AM
>Did you set in Cube : using debug or swd ? Do this.
As far as I know, doing this is for documentation purposes only - to mark the pins as in use. But you can debug the chip even without defining this (not sure about SWO, actually). I could be wrong - but I've never seen any code generation that actually results from setting this. Still, definitely good practice.
The rest of Ascha's warnings explain several ways you could get yourself into exactly the type of situation OP describes.
2024-08-05 05:33 AM
right, no "debug" setting needed, because chip begins after power up with the jtag pins enabled.
So as long as nobody writes any other setting to these pins...debug possible.
You can see this in rm , gpio settings at reset :
-> not all 00 , some on alternate function -> for JTAG/SWD etc.