'st-info --probe' returns 'unknown device', works with STMCubeProgrammer

[KevinLeif]

• Programmer/board type:
  • Manufacturer: STMicroelectronics
  • Product: STLINK-V3
  • Serial: 002100423438511734313939
• Operating system an version: Ubuntu 20.04.3 LTS
• stlink tools version and/or git commit hash: st-flash 1.6.1-96-gbf41f14 and st-flash 1.7.0
• stlink commandline tool name: st-info, st-flash
• Target chip (and board, if applicable): STM32H743ZIT6U - Nucleo-H743ZI2

Commandline output:
I get a error while flashing a binary.

/usr/bin/st-flash --reset --format=binary write foo.bin 0x8000000 <

st-flash 1.7.0
2021-09-02T07:49:24 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2021-09-02T07:49:24 WARN common.c: Invalid flash type, please check device declaration
Failed to connect to target
The terminal process "bash '-c', '/usr/bin/st-flash --reset --format=binary write foo.bin 0x8000000'" failed to launch (exit code: 255).

Same error with the st-flash version 1.6.1. If I'm right the flash type is determined via the chip id.
st-info 1.6.1

st-info --probe
Found 1 stlink programmers
 serial:     303032313030343233343338353131373334333133393339
 hla-serial: "\x30\x30\x32\x31\x30\x30\x34\x32\x33\x34\x33\x38\x35\x31\x31\x37\x33\x34\x33\x31\x33\x39\x33\x39"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

st-info 1.7.0

/usr/bin/st-info --probe
Found 1 stlink programmers
  version:    V0
  serial:     002100423438511734313939
  flash:      0 (pagesize: 0)
  sram:       24
  chipid:     0x0000
  descr:      unknown device

If I run the STM32CubeProgrammer instead I can connect and flash without any issues.
Stlink Firmwareversion: V3J5M2 (updated as suggested in contributing.md)

Device: STM32H7xx
Type: MCU
Device ID: 0x450
Rev: V
Flash Size: 2 MB
CPU: Cortex M7
Bootloaderversion: 0x90

Therefore I guess the hardware is fine. I've tried another board H7 board as well, same issues.
I've checked the procedure with my hardware on a colleagues setup and everything worked fine. (1.6.1 and 1.7.0, Ubuntu20 as well)
The chip id is returned as expected. Flashing works as expected. Do I miss something? Is there additional driver or some setting I've forgot?

[lucasdietrich]

I'm facing the same issue at the difference that I'm using STLink/V2-onboard. Moreover I managed to have both commands to work in the past with the version of the tool stlink-tools v1.6.0.

It stopped working and I never managed to reprogram the board using "stlink-tools" on Linux, I had to got back to on windows and program with the STM32CubeIDE/programmer.

I have a board stm32f429zi (NUCLEO-f429zi) for which all is working perfectly and constantly fine.

• Programmer/board type: STLink/V2-onboard (V2.J39.M27)
• Operating system an version: Ubuntu 20.04.1
• tested v1.6.0 and /v1.7.0
• st-info / st-flash
• Target chip: STM32L011K4 (NUCLEO-L011K4)

Commandline output:
I'm getting invalid probe information with st-info --probe :

Version v1.7.0

Found 1 stlink programmers
  version:    V0
  serial:     FF555557838667143150
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0xffffffff

Version v1.6.0

lucas@laptop-dev:~$ st-info --probe
Found 1 stlink programmers
 serial: 303636444646353535353537383338363637313433313530
openocd: "\x30\x36\x36\x44\x46\x46\x35\x35\x35\x35\x35\x37\x38\x33\x38\x36\x36\x37\x31\x34\x33\x31\x35\x30"
  flash: 0 (pagesize: 0)
   sram: 0
 chipid: 0x0000
  descr: unknown device

And then I can't erase : using st-flash erase:

st-flash 1.7.0
2022-02-13T18:08:15 INFO common.c: Loading device parameters....
2022-02-13T18:08:15 WARN common.c: Invalid flash type, please check device declaration
Failed to connect to target

Expected/description:

When It was working in the past (st-flash also worked at this moment).

Found 1 stlink programmers
 serial: 303636444646353535353537383338363637313433313530
openocd: "\x30\x36\x36\x44\x46\x46\x35\x35\x35\x35\x35\x37\x38\x33\x38\x36\x36\x37\x31\x34\x33\x31\x35\x30"
  flash: 16384 (pagesize: 128)
   sram: 8192
 chipid: 0x0457
  descr: L011 device

Hope it helps

[Nightwalker-87]

@lucasdietrich Thanks for the input. However the comparison with older versions does not help here due to larger refactoring work and restructuring in the library recently. One would clearly need to review the current state in the develop branch.

[Nightwalker-87]

@lucasdietrich Sorry for the long delay. I finally found some time to review some issues.
Do you still have the setup / toolset to give this another try? If so, one should solely focus on Release v1.7.0 and subsequent commits. Can you git bisect?

[Nightwalker-87]

Support for STM32H7 devices was not present before Release v1.7.0.
This feature was added to the develop branch in commit 1e20921.

@lucasdietrich Your attempt with the L0 device leads to the same result as with the H7, as it is running through the same routine in the code, but must have a different cause. Need to investigate further which then may reduce efforts for bisecting.

[Nightwalker-87]

@lucasdietrich Looking closer at this, I believe you should try to reproduce your case with Release v1.7.0.
Earlier releases do not compile any more with recent toolchains, so this is clearly not an option for any debugging attempts on the recent dev environment I use to maintain the codebase.

For users with a STM32L011K4 and/or a STM32H743ZIT6U device and a STLink/v2 programmer (we may extend the testing to the STLink/v3 in a second step):

Please proceed as follows:

1. Checkout Release v1.7.0 via git
2. Update your programmers to the latest firmware available from ST-Microelectronics:
   ST-LINK, ST-LINK/V2, ST-LINK/V2-1, STLINK-V3 boards firmware upgrade
3. Run the following command sequence in the working directory:

sudo make clean
sudo make install && sudo make uninstall && sudo make clean
sudo make install
st-info --probe

... and report back the output you receive.

[Nightwalker-87]

@fdelbos I just noticed in #1253 that you have a L011K4 Nucleo. Can you help testing?

[fdelbos]

@Nightwalker-87 sorry about that, i m remote working for a few months and wont have access to the kits until spring.

[Nightwalker-87]

@fdelbos Thanks for the quick response. Well never mind... 😐

[lucasdietrich]

Did the steps you mentionned above, I'm having the following result with a NUCLEO-l011k4 board :

lucas@vmdev:~/stlink$ ./build/Release/bin/st-info --probe
Failed to parse flash type or unrecognized flash type
Found 1 stlink programmers
  version:    V2J31S21
  serial:     066BFF555557838667142135
  flash:      16384 (pagesize: 128)
  sram:       8192
  chipid:     0x457
  dev-type:   STM32L0xxx_Cat_1

• Ubuntu 20.04.4 LTS
• ST Link firmware version: V2J39M27 (latest proposed by STCubeProgrammer)

Moreover erasing and programming the chip works for me now 👍

[Nightwalker-87]

@lucasdietrich Oh, that is good news! Thanks for the feedback. 🥇

The Failed to parse flash type or unrecognized flash type turned out to be a misplaced output message in combination with a improper reading of device configuration parametres. It has been fixed in commit aee9a47.

[Nightwalker-87]

@EmanueleGiacomini I've noticed in #1249 that you have similar hardware which would qualify for testing here.
Could you give it a try? It would be great and may allow to finally resolve this issue...

[Nightwalker-87]

Alternatively: @ronangaillard and/or @benjinne - you may also give it a try, if you fancy.

[benjinne]

I don't remember the exact issue I had, but around Oct 25th, the latest release wasn't working so I built it from the main branch and it started working

[Nightwalker-87]

@benjinne Oh well, one may give it a try on the current develop with the same procedure as described earlier,
but I expect it to work as well. At least, it does not happen on my STM32F10x boards with STLink/v2 which are the only devices I have around for testing currently.

[defyingphysics]

I have tested using a Nucleo H7 A3ZI-Q
When using the dev branch (note ./, run from /bin in dev branch with sha: d053470):

~/Desktop/stlink/bin  develop
❯ ./st-info --probe
/usr/share//stlink/chips: No such file or directory
Found 1 stlink programmers
  version:    V3J10
  serial:     004F003E3038510734333935
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x480

However it seems the 1.7.0 release is working just fine. ( have installed 1.7.0)

~/Desktop/stlink/bin  develop
❯ st-info --probe
Found 1 stlink programmers
  version:    V3J10
  serial:     004F003E3038510734333935
  flash:      2097152 (pagesize: 8192)
  sram:       131072
  chipid:     0x0480
  descr:      H7Ax/H7Bx

[davidgiven]

I'm getting the same thing, with 1.7.0 (on Debian Linux sid). I'm using a RobotDyn ST32 MINI Black Pill. STM32CubeProgrammer reports this as an STM32F101/F102/F103, device ID 0x410, Rev X, Cortex-M3. st-info --probe says this:

$ st-info --probe 
Found 1 stlink programmers
  version:    V2J40S7
  serial:     352605012A12354D314B4E00
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device

[davidgiven]

...addendum to the last: after removing the two boot mode jumpers st-info worked fine... and then after reinserting the jumpers it continues to work fine.

I have no idea what happened or why, but at least it's working now.

[Nightwalker-87]

Very interesting indeed... This sounds as if a temporary GND-disconnect could play a role...

[davidgiven]

For reference: what are the canonically correct jumper positions for flashing? I flashed a firmware which turns off the debugging ports, and now I can't make st-link work at all! This suggests that I only had it working at all previously because it was booting into the user application which happened to leave the debug ports open. There should be a jumper setting for forcing it into the bootloader, right?

n/m, I had a bad cable. However, even with the right cable (and right jumper settings) I am having trouble connecting. It'll work fine for an extended period of time and then just stop working. I have noticed that connecting with STM32CubeProgrammer and then disconnecting again will get st-link working again.

[Nightwalker-87]

Concluding review:

The testing results from @lucasdietrich and @defyingphysics verify that this issue is fixed.
Investigation of this issue reveals that necessary support for H7 devices made it into the master branch with #1099 on 11 Mar 2021 together with several other changes. By that time this was unintended and by mistake, as these topics were all still considered under development by then. Nevertheless we can safely assume that by the official release of version v1.7.0 on 25 Apr 2021 all necessary changes were complete. Apart from this we may assume that there were some leftovers from previous installations causing the original issue to appear. Here we recommend to do a manual clean-up of remnant files and to start over again with a clean install.

In this context we can mark this issue as resolved by Release v1.7.0 and even more precise by #1052.