Unable to flash Blue Pill

[Wosamarak]

Hello,

looks like I do something wrong, as I can't flash dap42 to an blue-pill.

• Using Windows 10 20H2, GNU Arm-none-eabi 10.2.1, Git bash
• Its a 128kB device, tested with STMFlashLoader.
• I am able to flash dapboot, it is recognized in Windows and appears as "DAPBoot DFU Bootloader" in the device manager.
• lsusb shows no problems:

Bus 003 Device 007: ID 1209:db42
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1209
  idProduct          0xdb42
  bcdDevice            1.11
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001b
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254
      bInterfaceSubClass      1
      bInterfaceProtocol      2
      iInterface              4 DAPBoot DFU
      Device Firmware Upgrade Interface Descriptor:
        bLength                             9
        bDescriptorType                    33
        bmAttributes                       11
          Will Detach
          Manifestation Intolerant
          Upload Supported
          Download Supported
        wDetachTimeout                    255 milliseconds
        wTransferSize                    1024 bytes
        bcdDFUVersion                   1.10
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x001d
  bNumDeviceCaps          1
  Platform Device Capability:
    bLength                24
    bDescriptorType        16
    bDevCapabilityType      5
    bReserved               0
    PlatformCapabilityUUID    {3408b638-09a9-47a0-8bfd-a0768815b665}
      WebUSB:
        bcdVersion    1.00
        bVendorCode      1
        iLandingPage     1 https://devanlai.github.io/webdfu/dfu-util/
can't get debug descriptor: No such file or directory
Device Status:     0x0000
  (Bus Powered)

I have built DAP103-BLUEPILL-DFU.bin, as this should be the right binary, when a DFU bootloader is present.
I went in the ./src subdirectory, and started there make TARGET=STM32F103-BLUEPILL-DFUBOOT dfuse-flash, here is the first thing, where I am struggeling: It looks like, that DAP42.bin is hardcoded, and the TARGET definition is not honored.
dfu-util -d 1209:da42,0483:df11 -a 0 -s 0x08000000:leave -D DAP42.bin

This leads to an dfu-util error:
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 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/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
No DFU capable USB device available

However a dfu-util -l
shows:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 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: [1209:db42] ver=0111, devnum=7, cfg=1, intf=0, path="3-5.4.6", alt=0, name="DAPBoot DFU", serial="194425875177485752FF7306"

The error stays the same, when I use 'DAP103-BLUEPILL-DFU.bin' as the binary.

Same happens, when I correct the USB VID/PID address in 1209:db42,0483:df11, as this is the PID, the device appears in the device-manager.

Playing with all parameters I came up to this short command:
'dfu-util.exe -d 1209:db42 -a 0 -D DAP103-BLUEPILL-DFU.bin' , the first, where dfu-util succeded, but with an error:

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 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/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1209:db42
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download        [=========================] 100%        13652 bytes
Download done.
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status after completion

After this, the device is dead: Nothing happens, when un and re-plugging, even not a single USB-error. Its just completly dead.
I need to go back, set the BOOT0-jumper and reflash the bootloader.

Thats where I stand now clueless.

[devanlai]

Hi @Wosamarak,

I'm not sure why the final result isn't working, though there are some areas where I could probably make the build and flash process a bit less confusing.

I wrote the main Makefile under src/ first, and it only concerns itself with one target at a time. Actually, it does a pretty bad job handing when the TARGET variable is changed, which is why I normally do a clean build whenever I switch between targets. As far as it knows, it always wants to build DAP42.bin and flash it, even if the actual target is not the original DAP42 hardware. It's only the release Makefile that adds understanding that we have multiple build flavors and that it'd be confusing for all of the firmware files to have the same name, so it copies and renames them.

The other confusing part is that there are two similarly named rules, dfuse-flash and dfu-flash. dfuse-flash targets the STM32F042 DfuSe ROM bootloader, whereas dfu-flash targets regular DFU bootloaders like dapboot. For your purposes, dfu-flash would have been the right one to use. However, your final DFU command is functionally the same as the one that the Makefile rule would have run, so I'm not sure what's up there.

The "unable to read DFU status after completion" is normal for dapboot, even when it succeeds. Maybe one day I'll get around to making sure that false negative doesn't happen.

Could you attach a copy of the DAP103-BLUEPILL-DFU.bin you're flashing? Alternatively, I've attached a zipped copy of a locally built copy of DAP103-BLUEPILL-DFU.bin that works for me that you might try flashing.
DAP103-BLUEPILL-DFU.zip

[Wosamarak]

Hello,

something must be different between our compilers. My binary is 144 bytes bigger than yours, but yours is working!
DAP42.zip

Right now, I have no clue, whats going on. And: You are right: The error message regarding the DFU status is also appearing here.

In the meantime I also tried some more things. As my dfu-util 0.9 was not willing to give me verbose information, I went to dfu-util 1.0 from their sourceforge site. This is unwilling to flash even your binary, stating that the file ID does not match the device ID.
That happens when flashing while dap42 is running, as well, when only dapboot is flashed.

'dfu-util.exe -d 1209:da42 -D build/DAP103-BLUEPILL-DFU.bin'
'''
dfu-util 0.10

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2020 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/

Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1209:da42
Run-time device DFU version 011a
Claiming USB DFU Runtime Interface...
Determining device status: Device does not implement get_status, assuming appIDLE
Device really in Runtime Mode, send DFU detach request...
Device will detach and reattach...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Error: File ID 0000:0000 does not match device (1209:da42 or 1209:db42)
'''
Attention: dfu-util 1.0 now reclaims being version 0.1!

[devanlai]

Hmm, well, now I'm even more puzzled.

I built a copy of dfu-util from git tag v0.10 and I can't see get the File ID error to reproduce. The file VID/PID is initialized to 0xffff in the absence of a DFU suffix (I don't build the DFU-suffix into the bin files, though maybe I should add a Makefile rule to build a proper .dfu file someday), so it's bizarre that dfu-util would fall into that error case and report a file VID/PID of 0000:0000.

Additionally, I loaded the DAP42.bin from your attachment with dfu-util and it seems to run just fine on my bluepill, so I'm not sure what's going on there. If it still seems to be dead after loading via dfu-util, could you try reading back the contents of flash with the ROM bootloader or a debugger and confirming that the firmware bin was loaded without any unexpected modifications?

[Wosamarak]

I disassembled both binaries and tried to compare, but unfortunately the code is very different. The difference starts already in the first lines, where just different registers are used. So comparing binaries makes less sense (however I attach an difference-report).

In addition I added some more C and CXX flags: 'CFLAGS += -Wa,-adhln=$@.s -g -fverbose-asm', to create additional assembler files with corresponding c-files. Comparing those with yours, should reveal more details about the difference.
diff_DAP42.zip
src.zip

[devanlai]

I was originally concerned that there might be latent bugs in the source code that might have surfaced when compiling with the newer version of gcc, but since your firmware binary seems to run fine on my bluepill, I no longer think that's likely to be the root cause of your problems.

At this point, other than ruling out weirdness with dfu-util, there's not a lot I can do to troubleshoot this remotely. If you want to keep digging, you could flash a second bluepill or find another debugger and then debug the firmware to see why it fails to enumerate. Otherwise if the version of firmware I built is working for you when you flash it, you could just stick with that.

[Wosamarak]

Thanks for all your help! For the first step I will stick with your firmware, as that is running. And yes: I will try it with another Bluepill. Maybe mine has some flash problem at the end of the slightly larger code.