Nucleo-H755ZI-Q no longer programmable

[TomC1]

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

[Amel NASRI]

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

[BarryWhit]

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.

[AScha.3]

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 .

[BarryWhit]

>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.

[AScha.3]

@BarryWhit ,

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.