2025-02-14 05:23 AM - last edited on 2025-02-14 05:55 AM by Peter BENSCH
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...
2025-02-14 05:41 AM
> 17:07:00:317 : received memory address is wrong or unsupported
What file are you trying to flash? Can you attach it here?
2025-02-14 05:50 AM
2025-02-14 07:06 AM
> 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.
2025-02-14 07:32 AM
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
2025-02-14 07:35 AM
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.
2025-02-14 07:48 AM
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.)
2025-02-14 11:37 AM
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.
2025-02-14 12:01 PM
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?
2025-02-14 02:07 PM
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