STM32CubeProgrammer not working with STM32F072 for USB DFU

[DavePfz]

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...

[TDK]

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

[DavePfz]

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

[TDK]

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.

 

[Pavel A.]

> 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]

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

[gbm]

Ok, guys. I was too lazy to signal this problem to ST, but it really IS a problem. Tried with few different boards under different scenarios. The current STM32Cubeprogrammer (2.18, but it was the same with 2.17) is unable to connect to STM32F072 in DFU mode. Actually I succeded maybe twice per over 100 trials and there is no deterministic path for this success.

So please, dear ST fellows, investigate and fix the problem. The same behavior may be observed with BOOT0 forced high and when invoking the bootloader from firmware (going through software reset to ensue clean chip configuration). DFU is correctly detected but once you try to connect, there is a message about memory being protected. Power off/on doesn't fix it.

[DavePfz]

So I'm not totally crazy!

Thanks

[STOne-32]

Dear @DavePfz ,

I confirm that we are working on such behavior in priority. Can you please try to confirm that inserting a Full speed hub or any hub between the Laptop/desktop and the board is fixing the issue ?  If yes, we have the hypothesis but needs to be confirmed . Thanks a lot in advance ,

Ciao

STOne-32

[DavePfz]

I used a Belkin F4U017 hub and was able to connect and perform various operations - program, erase, verify, etc. So that is one step further.

However, on programming and resetting, it still came up as STM32 BOOTLOADER in Windows 10 regardless of the state of the BOOT0 pin. (In STM32CudeProgrammer nBOOT1 is checked.) This may be a different problem.

I tried using the STLINK-V3SET to program, but on trying to connect, it always reports "Error: ST_LINK Error (DEV_TARGET_RESET_ERR)" I verified that the NRST pin is high.

So, I'm not out of the woods yet.

Again, any suggestions welcome.

Thanks

[DavePfz]

Oops! My bad. I got focused on the '07' and forgot the rest.

Just to verify, the part I am trying to program is the STM32F072CB.

Back to the drawing board.

Thanks

[DavePfz]

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!

[teva]

I assume you meant 2.19? 

[teva]

Is there any update to this problem from the ST devs? How close are we to this being solved?

(I also was able to solve this behaviour through a USB Hub)

Best,

 

Teva