Issue occured after programming STM32H743 in DFU with STM32CubeProgrammer

[SilasRamsay]

So I tried upgrading the firmware. I first downloaded the STM32CubeProgrammer, linux version, on the my computer. Then I got the device into DFU mode as per instructions and attempted to flash the new firmware using the STMCubeProgrammer software. Afterwards, it did not restart and no longer goes into DFU mode. It does not show in lsusb at all. It previously did as an STM device in DFU mode, but now its no show. The MCU is an STM32H743. I found an SWD port on the PCB and connected to it, again using the STM32CubeProgrammer software but with an STLinkV2. On selecting the STLink option and clicking connect, the program reads the MCU details, but fails to read any data or flash a binary file.

When attempting to flash a new firmware I am getting 3 errors:

Error: Flash loader cannot be loaded

Warning: The core is locked up

Start operation achieved successfully

Can I unlock the core and get it into DFU mode, or at least flash the new firmware?

Beyond installing it the other day and following the firmware flashing instructions, I have no provious familiarity with the STM32CubeProgrammer software.

Any help appreciated.

[SofLit]

What about Boot pin? did you set it again to the GND?

[SilasRamsay]

Not sure about this. I am using an STLinkV2 and the header on the PCB that is marked SWD has the following pins and connections to the STLinkV2:

RST - RST

CLK - SWCLK

GND - GND

DAT - SWDIO

As per the above, I have connected RST to the RST pin on the STLinkV2, so I am assuming that the reset signal is being handled by the STLinkV2. Not sure whether RST on the PCB is connected to "the Boot pin"? Would have to check the datasheet and locate that and then check where it connects to. Also not sure what is meant by "set it AGAIN" to GND?

The instructions tell me to press down the two rotary controls, connect to USB, and then to power on the device.

[SofLit]

---

@SilasRamsay wrote:

it did not restart and no longer goes into DFU mode. It does not show in lsusb at all. It previously did as an STM device in DFU mode, but now its no show.

---

How did you enter DFU mode? without setting BOOT pin to VDD?

[SilasRamsay]

I can only assume that the button presses (2 x rotary and power button) mentioned in the flashing instructions took care of that. The device came up listed as "STM whatever in DFU mode" and on hitting Connect in the CubeProgrammer with it set to USB mode its details came up and so did some of its data content. I have not been able to get it to come up since it was flashed. At this point I was working only via the external USB connector.

I located the internal SWD interface later after this when it got bricked. There is also another header on the PCB that has tracks going directly to the MCU. Looking at the pin connections, this appears to be the UART3 interface on the chip. Is this hooking this up likely to be of any help? If it were UART0 I might expect that it would be, but not so sure about UART3?

Anyway, what does it mean when it says that the 'core is locked'?

CubeProgrammer is also indicating that its status is 'halted'. I tried hitting the 'Run' button but it came back with the same errors.

I don't know whether the chip got wiped and maybe needs a bootloader installing first, but I have just found appnote 2606 and am just going through it to find the right second on the STM32H7 devices. This is one massive file! Anyway once I have found and read the relevant section I will hopefully understand more about the boot on these STM chips.

[Rob.Riggs]

@SilasRamsay you really should be talking to the vendor of the board you are attempting to flash.

[SilasRamsay]

That is fair comment and I have reached out to them now as well.

I was hoping that I vould at least recover the use of the MCU so that even if I can no longer use the firmware it came with, I could use the hardware (MCU and display) for some other project.

Thanks.

[SilasRamsay]

I have solved the probem! There are two problems really. One is a bug in the STM32CubeProgrammer software and the other a lack of validation.

The first problem is that the CubeProgrammer fails to find the loader file which is evidenced by the error:

"FlashLoader 0x cannot be loaded"

when one connects to the MCU. The program can read the MCU details including its ID (0x450 in this case) but then doesn't find the correct file 0x450.stldr. The problem and workaround were outlined in this article:

https://stackoverflow.com/questions/78850472/stm32cubeprogrammer-flash-loader-cannot-be-loaded

I copied the file 0x450.stldr to 0x and on subsequent launch of CubeProgrammer, the error disappeared. Not only that, I could now flash the firmware as well. I don't know whether this affects the Windows version as well, but I was using the latest Linux version of STM32CubeProgrammer, downloaded only yesterday. I would request that STM fix this bug please.

The second problem was that CubeProgrammer does not validate .hex files, but instead treats then as a binary file. This is what led to the device getting incorrectly flashed in the first place. In older and now deprecated tools such as DFuSe, one had to convert from .hex to .bin, but I was under the impression that CubeProgrammer can process either .bin or .hex files directly, although I could not find any confirmation of this. Given my experience, evidently, depite claiming to encompass all of the features neccessary for accessing and flashing MCU's in one package, I could not find a function to convert .hex to .bin and a copy of the deprecated DFuSe was rather difficult to find although I came across it eventually.

Evidently, files still need to first be converted to .bin with DFuSe. Once that was done, fixing the problem was fortunately a simple matter of flashing the firmware again using the .bin file. It would have been helpful to at least pop up a warning when a user specifies a .hex file that a conversion to .bin is neccessary and actually provide a feature to carry out the conversion without having to spend a lot of time searching for a copy of the deprecated software which, it seems, can only be found on a 3rd party website.

After the fimware was flashed again uing the .bin file and the device physically disconnected from the SWD interface, it worked as expected and can now be put into DFU mode if required as well.

I appreciate that the software is made available for free and am grateful for that, but it would be helpful if these issues could be addressed by STM.