ST-LINK on STM32-H437ZI2 stopped working after installing MicroPython

[codedump]

Hello,

I've managed to use st-link to install MicroPython on an STM32-H743ZI2 Nucleo-144 board weeks ago, using @Ant-ON's version.

Recently I wanted to dive deeper into STM32 programming, but the ST-LINK doesn't seem to work after flashing with MicroPython:

root@7597058af286:~# st-info --probe
Found 1 stlink programmers
 serial:     303032413030334633343338353130433334333133393339
 hla-serial: "\x30\x30\x32\x41\x30\x30\x33\x46\x33\x34\x33\x38\x35\x31\x30\x43\x33\x34\x33\x31\x33\x39\x33\x39"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

I've also tried it with the current develop branch yesterday, same result. It appears to me as if flashing MicroPython somehow killed the ST-LINK interface and I don't understand how. According to MicroPython people this isn't supposed to happen, so now I'm asking here as my next station: is this normal? Is this a bug? What do I need to do to investigate?

I have a container image built for working with stm32 stuff if anyone feels like reproducing.

Thanks & Cheers,
Florin.

[Ant-ON]

@codedump My changes are already included in the main branch. You may use develop branch. The MCU may be in sleep mode. Can you try run st-info --probe --connect-under-reset?

[paullee2018]

Hi,

I am also experiencing something similar.

I currently connected the openmv h7 plus to the stlink v2 programmer but when I run st-info --probe, I get the following output

Found 1 stlink programmers
serial:
hla-serial: ""
flash: 14152 (pagesize: 225)
sram: 2257604624
chipid: 0xffffffff

and when I run st-info --probe --connect-under-reset, I get the following

Found 1 stlink programmers
serial:
hla-serial: ""
flash: 14152 (pagesize: 1041)
sram: 204139
chipid: 0xffffffff

It doesn't look right to me. Each time I run either commands, the sram values always changes. The version of stlink is v1.61.

Regards
Paul

[codedump]

(I had -- and still have -- a lot of supplementary information on this, but at the time of creation 3 weeks ago, the thread was all of a sudden closed and only people "who have contributed to this project in the past" could comment on this issue. I was cut off in the middle of the conversation, so to speak -- any of the responsible care to please explain why?)

Anyway. Here's more.

--connect-under-reset also fails for me.

Regarding reset process itself: f I reset the device and keep
the reset button pressed, and repeatedly try to st-info --probe, I
get different results after few seconds. First is this:

  ...
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x03e8

Then few seconds later, upon repeatedly probing with st-info:

  ...
  chipid:     0x0001

Then, if I release the reset button, finally:

  ...
  chipid:     0x000a

And it stays that way. This is true also for the develop branch (was true
3 weeks ago, I didn't bother checking since public discussion was shut off).

Meanwhile I've downloaded the official STM32CubeProgrammer. It also
fails to connect in normal mode, but it does connect under
reset. Here's a log of STM32CubeProgrammer, in case it's any help.

09:44:06 : ST-LINK SN  : 002A003F3438510C34313939
09:44:06 : ST-LINK FW  : V3J2M1
09:44:06 : Board       : NUCLEO-H743ZI
09:44:06 : Voltage     : 3.26V
09:44:06 : ST-LINK error (DEV_TARGET_CMD_ERR)
09:44:06 : ST-LINK SN  : 002A003F3438510C34313939
09:44:06 : ST-LINK FW  : V3J2M1
09:44:06 : Board       : NUCLEO-H743ZI
09:44:06 : Voltage     : 3.26V
09:44:06 : Error: ST-LINK error (DEV_TARGET_CMD_ERR)

Under reset:

09:44:14 : ST-LINK SN  : 002A003F3438510C34313939
09:44:14 : ST-LINK FW  : V3J2M1
09:44:14 : Board       : NUCLEO-H743ZI
09:44:14 : Voltage     : 3.26V
09:44:14 : SWD freq    : 24000 KHz
09:44:14 : Connect mode: Under Reset
09:44:14 : Reset mode  : Hardware reset
09:44:14 : Device ID   : 0x450
09:44:14 : Revision ID : Rev V
09:44:14 : UPLOADING OPTION BYTES DATA ...
09:44:14 :   Bank          : 0x00
09:44:14 :   Address       : 0x5200201c
09:44:14 :   Size          : 308 Bytes
09:44:14 : UPLOADING ...
09:44:14 :   Size          : 1024 Bytes
09:44:14 :   Address       : 0x8000000
09:44:14 : Read progress:
09:44:14 : Data read successfully
09:44:14 : Time elapsed during the read operation is: 00:00:00.001

The funny part is that the board now, after having connected once
under reset, always connects using STM32CubeProgrammer even in
normal mode, while it still doesn't using st-info --probe (with or without
--connect-under-reset). This is even true if I power-cycle the
device.

I've also tried the blackmagic tools. Those gave me an essential hint
that I should update the firmware of the STLink device. After a firmware
update, it apparently works, with every tool (STM32CubeProgrammer,
ST-Util, ...):

$ st-info --probe
Found 1 stlink programmers
  version:    V3J7
  serial:     303032413030334633343338353130433334333133393339
  hla-serial: "\x30\x30\x32\x41\x30\x30\x33\x46\x33\x34\x33\x38\x35\x31\x30\x43\x33\x34\x33\x31\x33\x39\x33\x39"
  flash:      2097152 (pagesize: 131072)
  sram:       131072
  chipid:     0x0450
  descr:      H74x/H75x

In essence, I think st-util's misbehavior here is two-fold:

• It doesn't properly connect with older firmares. While there may be a problem that prevents this, apparently there is a way to do it, since the STM32CubeProgrammer does it.
• It doesn't recognize that it has a problem with the current firmware version -- apparently there is a way to do this, too, since blackmagic does it.

One way or another, there definitely is a bug in there somewhere.

[Ant-ON]

@codedump When the reset button is pressed, the microcontroller is in an undefined state. And it's okay if the results are chaotic.

I looked at the code in detail. Parameters '--probe' and '--connect-under-reset' are not may used together. You may use other parametrs with '--connect-under-reset' such as '--chipid'.

[codedump]

@Ant-ON --probe --connect-under-reset wasn't my primary use case anyway, it was just something I did to give you the data you requested :-) That said, even if it's not supposed to be used together, it works now (after STLink firmware upgrade to version V3J7M3).

--chipid also works, but this is not going to be terribly helpful -- as I said, now my board has a new STLink firmware, so I can't try the old setup.

From what you're saying, I believe we're looking at at least two different bugs in st-info. One is the fact that it accepts --probe and --connect-under-reset together even if they're not supposed to work together (?). The other is that st-info --probe connection issue. It ideally it should connect; the least it should do is fail gracefully if that's not possible.