[STM32F407VG]: unknown chip id! 0x374b

[frankplow]

• I made serious effort to avoid creating duplicate or nearly similar issue
• Programmer/board type: [STLINK/V2-A onboard]
• Operating system and version: [Linux (5.11.7-arch1-1)]
• stlink tools version and/or git commit hash: [v1.6.1 & 1.6.1-277-g6f793d6]
• stlink commandline tool name: [st-flash]
• Target chip (and board, if applicable): [STM32F407VG (STM32F407G-DISC1)]

The STLINK/V2-A was working as expected for some time, then seemingly randomly stopped working. Initially, it failed to flash or erase (note: st-flash erase is used here, but running st-flash write results in the exact same errors in all cases) instead giving the output:

% st-flash erase
st-flash 1.6.1
2021-04-06T18:32:05 WARN common.c: unknown chip id! 0x5fa0004
Failed to connect to target

As per recommendation in #1040 and #1047, I upgraded the STLINK firmware. It is now running version V2J37M27. This firmware upgrade did not fix the issue, and appeared to make little difference to the output of st-info (apologies, I lost this output from before the upgrade). The read chip ID was changed to 0x374b however, so I now get the output:

% st-flash erase
st-flash 1.6.1
2021-04-07T14:12:34 WARN common.c: unknown chip id! 0x374b
Failed to connect to target

If I use the development version of stlink, I get

% st-flash-dev erase
st-flash 1.6.1-277-g6f793d6
2021-04-07T14:18:31 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target
% st-flash-dev --connect-under-reset erase
st-flash 1.6.1-277-g6f793d6
2021-04-07T14:19:18 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target

and if the reset button is held:

% st-flash-dev --connect-under-reset erase
st-flash 1.6.1-277-g6f793d6
2021-04-07T14:21:22 INFO common.c: F4xx: 192 KiB SRAM, 0 KiB flash in at least 16 KiB pages.
Mass erasing

however no erasure actually occurs.
Following the advice in #1012 to tap reset then immediately execute the erase command results in:

% st-flash-dev --connect-under-reset --reset erase
st-flash 1.6.1-277-g6f793d6
2021-04-07T14:31:22 INFO common.c: F4xx: 192 KiB SRAM, 1024 KiB flash in at least 16 KiB pages.
2021-04-07T14:31:23 WARN common.c: Failed to unlock flash!
Mass erasing
2021-04-07T14:31:23 WARN usb.c: NRST is not connected

Some assorted --debug, st-info and st-util outputs are provided here: https://pastebin.com/eYQJVwkz
Notably, the chip ID seems to be read as 0 by both st-info and st-util.

Expected/description:
The device is erased.

[Ant-ON]

@frankplow If you have a board with connected nrst pin, then you do not need to press the reset button. Judging by the fact that the --connect-under-reset option is help to detect target, then most likely the microcontroller goes into sleep mode or do critical configuration changes (for example remap the SWD GPIO).
I reworked the reset system a little more. Also some other improvements. You can try the branch https://github.com/Ant-ON/stlink/tree/fl_fix . Perhaps the results will be more interesting.

[frankplow]

Thank you, using that fork/branch has resolved the issue. NRST is connected directly to the Reset button, so the technique given in #1012 worked.

I have managed to reproduce the issue by uploading a specific binary (https://www.dropbox.com/s/mvo04e8oemirly4/mbed-os-example-blinky-baremetal.bin?dl=0). Here is the source of the file: https://arm-software.github.io/CMSIS_5/DSP/html/arm_dotproduct_example_f32_8c-example.html. I am compiling it using mbed-cli.
Outwardly I don't see anything wrong with it - it uses 20560 bytes of flash and 1792 bytes of SRAM, which is well within the board's capabilities, though I am inexperienced with embedded systems so somebody else may spot something I've missed.

[Ant-ON]

@frankplow There is no hardware configuration in the code. Apparently mbed-cli adds it for you. You may be using Mbed OS and it going into sleep (for example sleep with SysTick interrupt wake-up).

[frankplow]

I returned to this today, aiming to do a bit more testing and narrow down exactly what it was in that file causing the issue, and the binary above no longer creates the unknown chip id! error. I've restarted since then, but I think the issue was still reproducing 100% of the time after at least one restart. If I remember anything else I've done that may have inadvertently fixed the problem, I will post here but I'm at a loose ends.

@Ant-ON Yeah I omitted the detail of adding #include "mbed.h" to the file for the HW config. I'm using mbed bare-metal rather than the RTOS so I don't think that's the case, but as I say I'm new to embedded so may be mistaken.

[Ant-ON]

@frankplow Then I have no ideas yet, which leads to the inaccessibility of the target for debugging.
In general, flash of the target has been solved, as I understand it