Cannot build dfu bootloader for blackpillv2

[HrMitrev]

Hi,
Recently I started a discussion #1299 about adding support for custom dfu bootloader for the blackpillv2 platform. It turns out that it's already implemented, even though I think it may not be necessary for the genuine chips. Unfortunatelly following this discussion, additional fw update methods may be beneficial.

The problem is that, even though there is a way to build a custom bootloader for the blackpillv2 platform, attemting to do so results in build error: make PROBE_HOST=blackpillv2 OPT_FLAGS='-Os' ENABLE_RTT=1 BMP_BOOTLOADER=1:

  BUILD   lib/stm32/f1
  BUILD   lib/stm32/f4
  BUILD   lib/lm4f
make[2]: Nothing to be done for 'all'.
make[2]: Nothing to be done for 'all'.
make[2]: Nothing to be done for 'all'.
Load address 0x08004000 for BMPBootloader
 GEN include/version.h
  CC      command.c
  CC      remote.c
  CC      platforms/common/usb.c
  CC      platforms/stm32/dfucore.c
platforms/stm32/dfucore.c: In function 'get_dev_unique_id':
platforms/stm32/dfucore.c:333:23: error: 'FLASH_BASE' undeclared (first use in this function); did you mean 'HASH_BASE'?
  333 |         max_address = FLASH_BASE + (fuse_flash_size << 10U);
      |                       ^~~~~~~~~~
      |                       HASH_BASE
platforms/stm32/dfucore.c:333:23: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [Makefile:119: dfucore.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:17: all] Error 2

If I build with make PROBE_HOST=blackpillv2 OPT_FLAGS='-DFLASH_BASE=0x8000000UL -Os' ENABLE_RTT=1 BMP_BOOTLOADER=1, the build succeeds, but the resulting binary seems non functional.

I don't have much experience with usb or bootloaders, but I'll be thrilled to try to resolve this if someone has an idea what should I look up. Best case scenario it's just simple build system bug.

The only FLASH_BASE macro I can find in the project is at libopencm3/include/libopencm3/pac55xx/memorymap.h:32, but I doubt it has something to do with the stm32 MCUs

[dragonmux]

Just to note for continuity: We've had a discussion about this on Discord and have identified the commits where FLASH_BASE was inadvertently removed and then again where the probable bootloader startup regression was introduced and suggested a plan of attack to fix this issue.

Do please keep us updated on your findings :)

[ALTracer]

This issue is outdated due to my #1508, consider rebuilding and testing the BMP_BOOTLOADER. The resulting binaries both somewhat work, it's just I can't get the BMP DFU to reliably program the correct payload. ST DFU definitely works, so I should have a genuine chip.

[dragonmux]

There have been several compounding issues, and until HrMitrev indicates all of them have been resolved and they have a working from-repo bootloader we'll leave this issue open to help track fixing this regression.

[HrMitrev]

Hi! I'm actively following the whole blackmagic project and I have compiled the latest updates but unfortunately the dfu functionality is still broken on my side. There is no usb device detected when I flash blackmagic_dfu.hex.

If I build without the bootloader, the binary works fine, but loading new firmware via USB is not possible.

I too have observed that the HSE crystal on my blackpill board is 25MHz and I have tried to play around with the clocks, but without success. I can debug the bootloader binary with one more blackmagic board, but unfortunately I haven't had the time to play around with it more than a few hours over the last months

[ALTracer]

There is no usb device detected when I flash blackmagic_dfu.hex.

BMP DFU works, but there is a small issue in that on first reboot from ST DFU into BMP DFU it doesn't appear properly, maybe due to incomplete reset.

Without it standard BMP definitely resets into ST DFU, which should work from MaskROM of genuine stmf401/411 chips. We don't support Artery blackpill yet.

[HrMitrev]

My chip is marked as STM32F411CE, but as already mentioned it isn't genuine. Not sure if Artery is the manufacturer, but what I find interesting is that the blackmagic binary itself works absolutely fine - the device enumerates and can even reset into ST DFU from MaskROM(which is unusable). The problem comes when I compile with BMP_BOOTLOADER=1 - it does not enumerate and not even "unrecognized usb device" is shown (which now that I think about it may be a problem with the pullups on the USB dataline). So if one firmware(BMP flashed at 0x8000000) can run without a problem, the other should be able work too

[ALTracer]

The problem comes when I compile with BMP_BOOTLOADER=1 - it does not enumerate and not even "unrecognized usb device" is shown

Can you at least debug the BMP DFU over SWD/JTAG? I don't unmap the SWJ-DP pins in BMPBootloader. You can cherry-pick some commits from my fork which enable write verification and change clocks down to 48MHz, if deemed useful.

F411 has dwc2 otg core with pull-ups built-in to FS PHY, no external pullups necessary unlike for F103.

[HrMitrev]

Hi again!

Please accept my apologies, but after pulling and rebuilding the latest sources, blackmagic_dfu was not refreshed I think, because later when I tried again with fresh copy of the project everything worked just fine...

We also had a quick chat with @ALTracer about the sector erase functionality and while there is an interesting use cases, being able to erase specific block of memory after flashing small binary it is not so important to me and most of the users I think.

Most importantly now I can load the blackmagic_dfu binary into my Chinese clone of stm32f411ce and seamlessly update to the newest BMP firmware for the blackpill. Thanks very much @ALTracer!

[dragonmux]

Regarding erasing specific blocks of memory, that is actually already implemented in the firmware - see the erase_range monitor command. It takes a start and end address of a block of Flash and runs erase on it. Do note, this is destructive on the erase block size level, hopefully obviously enough.