STM32CubeProgrammer not working with STM32F072 for USB DFU

DavePfz · ‎2025-02-14

I have a design that I'm trying to bring up and program using the USB DFU capability. The board enumerates correctly in windows, but does not get into programming. It seems as though I have forgotten something, but don't know what to look for. I have checked the "Read Unprotect (MCU)" box.

I have attached the verbose log of one cycle. What happens when I try to connect is shown there and after a bit a window pops up saying to turn off the power to my device. When I do, the cycle repeats!

Thanks for any pointers...

DavePfz · ‎2025-04-01

Hi guys. This is to bring all up to date and close the issue.

I found that version 3.19 of the STMProgrammer has corrected this - as long as I connect through a hub. So for all practical purposes, I'm happy.

I did run into a secondary problem that may be of interest to some as an update to the program seems needed. Once I was able to program my board, it would always come up in STM32BOOTLOADER mode regardless of the state of the BOOT0 pin. I tracked this down to being the BOOT_SEL bit in the user portion of the Option Byte (address 0x1FFF F800, page 77/1017 of RM0091 Rev 10). Default for this bit is set, but somehow in the crazy process is got cleared. Since it doesn't show up in the User Configuration panel in the Option bytes of the STM32Programmer program, I did a direct read and wrote the default values. After that, the board behaves as expected.

Thanks for your patience!

View solution in original post

TDK · ‎2025-02-14

> 17:07:00:317 : received memory address is wrong or unsupported
What file are you trying to flash? Can you attach it here?

If you feel a post has answered your question, please click "Accept as Solution".

DavePfz · ‎2025-02-14

I don't believe this has to do with the specific file as I am only trying to connect to the device. Just in case, I tried loading the file first and then connecting. I'm attaching both the screen capture and the file.

Thanks

Pavel A. · ‎2025-02-14

> a window pops up saying to turn off the power to my device. When I do, the cycle repeats!

Do you toggle the BOOT0 pin on this thing? Typically to invoke the the built-in DFU bootloader you switch the BOOT0 pin. After programming you need to switch it back to run the user firmware. Otherwise the bootloader starts again.

DavePfz · ‎2025-02-14

I have tried various combinations: pulling it high just during reset, holding high during the attempt to connect, etc.

I have not been able to get to the point of programming as it refuses to connect.

Thanks

TDK · ‎2025-02-14

To be clear, you select usb1 as a device, then hit Connect, then it gives you these errors?

Serial number looks suspicious.

Can you connect over SWD and examine the relevant option bytes?

> I have checked the "Read Unprotect (MCU)" box.

Unless it's protected, you shouldn't do this. Device will need to erase itself and reset after you disable RDP.

If you feel a post has answered your question, please click "Accept as Solution".

DavePfz · ‎2025-02-14

You are correct on the procedure I am using: Select USB1 and hit [Connect]

I agree with you. Remember that this is the first time I've tried to use the USB DFU capability, so I am not sure what to expect.

The only reason I selected the "Read Unprotect (MCU)" box was because I got an error message indicating a need for it. (?)

I will try the SWD approach later, but it may not be until over the weekend. (Fortunately I designed the board so that a connector is available.)

DavePfz · ‎2025-02-14

OK. The weekend came early. I used the SWD via ST-Link and all seemed OK. I then programmed the file and it "appeared" to work, but things went downhill.

When I attempt the USB DFU now, USB1 is not found.

Also, when I attempt to connect via the ST-Link, I get the attached error window.

I'll examine the voltage levels, etc. closer, but would appreciate further pointers.

TDK · ‎2025-02-14

Are you sure the board is designed correctly and assembled correctly, particular with respect to power? Can you share a schematic?

It really should "just work" once you're in the bootloader. The F0 isn't new, I'd be surprised if there was a bug with accessing it. Do you have a F0 dev board you could try the same thing on?

If you feel a post has answered your question, please click "Accept as Solution".

DavePfz · ‎2025-02-14

Since this is an open source design that was started at Google and then continued by others, there's no problem sharing the schematic. My starting point was the project discussed at https://hackaday.com/2023/11/22/freshening-up-googles-usb-c-pd-sniffer/

I was more interested in making it more widely available (smallest part is 0603) and migrating it to the EAGLE CAD. The initial work was done over a year ago and it sat on the shelf until needed for another project.

The uP is on sheet 3 with the BOOT signal coming from sheet 2 - roughly right center. I don't think I have an 'F0' dev board here, but I have used the STM32L051 and STM32L071 in another design. There the DFU was via UART and I had no problems.

I am fairly sure I have a simple hardware problem, but just don't know where to look.

Thanks