#88 Download gets stuck on STM32H7 Rev V devices when erasing pages past 1MB point

[A Poiana]

We recently tried dfu-util on the new H7 rev V micro and noticed that page erases past the 1MB point get stuck in an infinite loop:

.
.
Erasing page size 131072 at address 0x080c0000, page starting at 0x080c0000
Poll timeout 1000 ms
Poll timeout 0 ms
Erasing page size 131072 at address 0x080e0000, page starting at 0x080e0000
Poll timeout 1000 ms
Poll timeout 0 ms
Erasing page size 131072 at address 0x08100000, page starting at 0x08100000
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
.
.

[A Poiana]

The issue seems to have affected STM32CubeProgrammer as well, but it was patched in v2.2.1:

"74031 STM32CubeProgrammer issue programming STM32H7 Rev V via DFU."

https://www.st.com/resource/en/release_note/dm00441049-stm32cubeprogrammer-release-v240-stmicroelectronics.pdf

[Anonymous]

I can reproduce this issue. Any insight on what the cause is?

[Tormod Volden]

If someone could do a USB trace on STM32CubeProgrammer v2.2.0 versus v.2.2.1 we would probably see how they work around it. Another option would be to simply ask ST about it, preferably someone who has bought these chips should ask.

[Meekdai]

hi, The following link records the difference between rev V and rev Y. The chapter 1.1 is about Flash, it should be helpful.

https://www.st.com/content/ccc/resource/technical/document/application_note/group1/95/22/7c/0c/57/de/4b/f9/DM00609692/files/DM00609692.pdf/jcr:content/translations/en.DM00609692.pdf

[Anonymous]

I captured a trace from STM32CubeProgrammer programming a binary file to address 0x8100000 (Start of bank2). The file is just four bytes 0x55555555.

[Tormod Volden]

Thanks for the link. It helps getting a general overview of the changes in rev V. If the bootloader uses bank swapping, the change "it is not possible to swap banks on the fly" sounds concerning and might be related.

As also seen in the reference manual for H74/H75 "RM0433" there are two 1MB banks so I understand the observed bootloader bug affects the second bank.

There are also the H742/H743 and H74/H75 errata documents but I couldn't find anything seemingly related in them:
https://www.st.com/resource/en/errata_sheet/dm00368411-stm32h742xig-and-stm32h743xig-device-limitations-stmicroelectronics.pdf

https://www.st.com/resource/en/errata_sheet/dm00530531-stm32h745747xig-and-stm32h755757xi-device-limitations-stmicroelectronics.pdf

Finally AN2606 lists different issues with the bootloader on H72/H73 and H74/H75 and H7A3/B3 devices:
https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

On which chips do you see the problem?

[Meekdai]

Thank you for your reply. I am using STM32H743XIH6 rev V.

[Anonymous]

Did you ever end up fixing this issue? I have the same problem :(

[Anonymous]

This takes more investigation, but looking at the difference in usb captures from dfu-util and CubeProgrammer: dfu-util sends the erase page command and waits indefinitely for a status other than Busy Download. CubeProgrammer only waits once, and then issues a Clear Status DFU command. It then issues get status commands, disregards the Error responses, and eventually gets an Idle response.

I edited dfu-util to do similarly and successfully used dfu-util to write spanning both banks:

--- src/dfuse.c 2021-07-05 08:11:49.000000000 -0400
+++ backup  2022-06-09 23:19:31.793455401 -0400
@@ -189,6 +189,7 @@
    int zerotimeouts = 0;
    int polltimeout = 0;
    int stalls = 0;

+  int attempts = 0;

    if (command == ERASE_PAGE) {
        struct memsegment *segment;
@@ -233,6 +234,9 @@
            dfuse_command_name[command]);
    }
    do {

+    if (attempts > 2) {
+      dfu_clear_status(dif->dev_handle, 0);
+    }
        ret = dfu_get_status(dif, &dst);
        /* Workaround for some STM32L4 bootloaders that report a too
         * short poll timeout and may stall the pipe when we poll */
@@ -275,11 +278,12 @@
        } else {
            zerotimeouts = 0;
        }
-   } while (dst.bState == DFU_STATE_dfuDNBUSY);
+    attempts++;
+   } while (dst.bState == DFU_STATE_dfuDNBUSY || dst.bState == DFU_STATE_dfuERROR);

    if (dst.bStatus != DFU_STATUS_OK) {

-       errx(EX_IOERR, "%s not correctly executed",
-           dfuse_command_name[command]);
+//     errx(EX_IOERR, "%s not correctly executed",
+//         dfuse_command_name[command]);
    }

Though certainly that needs more thought to implement.

[Luigi Calligaris]

Hi, I'm affected as well: the erase freezes around 1 MiB, where the second bank begins. I use the STM32H745XIH6 MCU.

The proposed fix above "solves" the issue but, as the OP mentions, it is a bit rough as it turns off error checking completely. I added code to restrict the status clear and the ignoring of the error only if an ST DFU device is connected (i.e. 0483:df11) and ERASE_PAGE is being performed. You can find it here:

https://sourceforge.net/u/luigicalligaris/dfu-util/ci/fix_stm32h7_page_erase/tree/

I'm not particularly proud of the fix atm, I'll think about how to make it more streamlined. @tormod, do you have an opinion on this?

[Tormod Volden]

Most dfuse devices have ID 0483:df11 so it is not the best filter. What is the dfu-util -l output? Maybe we can filter based on the alternate interface string, and on the bank flip?

[Luigi Calligaris]

Hi @tormod, the 0483 vendor ID is assigned to STMicroelectronics and df11 corresponds to "STM Device in DFU Mode" (see http://www.linux-usb.org/usb.ids), so this already restricts us to the specific vendor.

Maybe we could use the "200364500000" serial number, which looks very generic. It would be nice to see if this applies to other MCUs from ST or is specific to H7.

dfu-util -l output below:

$ src/dfu-util -l
dfu-util 0.11-dev

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=36, cfg=1, intf=0, path="1-2.2", alt=0, name="@Internal Flash   /0x08000000/16*128Kg", serial="200364500000"
Found DFU: [0483:df11] ver=0200, devnum=36, cfg=1, intf=0, path="1-2.2", alt=1, name="@Option Bytes   /0x5200201C/01*128 e", serial="200364500000"

[Luigi Calligaris]

Update: I refactored parts of dfuse_special_command, added the conditional state clear based on the serial number "200364500000". I tested that on the STM32H745XIH6 devices I have in lab (it works).

@tormod and others, can you test on your devices? Code is here in master:

https://sourceforge.net/u/luigicalligaris/dfu-util/ci/master/tree/