Not working with default crossfile

[Ganesharyal24894]

Hey, I am using default crossfile for configuration like this " meson setup build --cross-file=cross-file/blackpill-f401cc.ini " and I am able to compile and generate a .bin file as well but it does not list itself as a USB device in device manager. Is it possible that this is happening because of not having correct dependencies? I am using a blackpill board(401cc) so I have installed dependencies for 3rd party hardware using " sudo apt install libusb-1.0-0-dev libftdi1-dev libhidapi-dev ". I am using WSL(Ubuntu22) and stlink utility for flashing bmp firmware using clone stlink. Also after configuration in few places I can see, it says few fiiles are not found like ' bmputil found: NO' and few warnings "libopencm3 : YES 2 warnings" are these okay? I had done this on an Ubuntu machine it was not showing anything like this and my BMP was also working fine, probably because it had some other dependencies already installed that I am not aware of. I could not find any better place to ask this question please guide me on this.

picture of what I see in device manager when BMP is connected : adding some screenshots of what I see after configuration :

[ALTracer]

I am able to compile and generate a .bin file as well but it does not list itself as a USB device in device manager.

I guess you're flashing something wrong. Please post exact dfu-util commands used to flash the blackpill.

meson setup build --cross-file=cross-file/blackpill-f401cc.ini is technically producing binaries which will work on blackpill-f411ce, but also it defaults to BMDBootloader (that works faster than BOOT0 ST MaskROM), you need to flash it in the 0x08000000-0x08004000 page, then the payload firmware goes at 0x08004000 offset.

This expects ST MaskROM 0483:df11 and flashes the BMDBootloader, then asks MaskROM to jump into it dfu-util -d 0483:df11 -S 3698364A3132 --alt 0 -s 0x08000000:leave -D build-f411ce/blackmagic_blackpill_f411ce_bootloader.bin This expects BMDBootloader and flashes the BMF payload, then asks it to jump into it. dfu-util -d 1d50:6018 -S 3698364A3132 --alt 0 -s 0x08004000:leave -D build-f411ce/blackmagic_blackpill_f411ce_firmware.bin

Alternatively, use the old way which relies ONLY on ST MaskROM and omits BMDBootloader entirely. Configure the meson builddir with meson setup build-f411ce_maskrom --cross-file cross-file/blackpill-f411ce.ini -Dbmd_bootloader=false then compile and flash from ST MaskROM a payload at 0x08000000 now dfu-util -d 0483:df11 -S 3698364A3132 --alt 0 -s 0x08000000:leave -D build-f411ce_maskrom/blackmagic_blackpill_f411ce_firmware.bin Coincidentally, that's what the current instructions say https://github.com/blackmagic-debug/blackmagic/tree/main/src/platforms/common/blackpill-f4#firmware-upgrade-with-dfu-util Substitute your serialno, they are computed by similar algorithms now and should match across all three entities. If this works, I guess I need to update the platform readme.

[Ganesharyal24894]

st-flash write blackmagic_blackpill_f401cc_firmware.bin 0x08004000 this is the command I am using to flash the firmware with stlink-tools or I use stlink-utility software after setting the address to 0x08004000 which is shown as load address after config cmnd. .

and from where do I get the BMDbootloader to flash it in 0x08000000-0x08004000 page, I could not find it. I tried using the old way of omitting the BMDbootloader but I get the same results (blue led on board is ON and Invalid device in device manager ) .

[dragonmux]

Er, hang a second for a few things here:

First - the firmware has no dependencies that are not in-tree or a Git submodule (libopencm3 is tied in as a Git submodule and is the dependency), but it is somewhat sensitive to the compiler used. You have not mentioned what compiler you have used.

Second - the dependencies you installed are only for BMDA and all have fallbacks which Meson will automatically use but change nothing about the firmware. Not finding bmputil will only mean that the flash target (ninja flash) will not be available for automating pushing firmware to the board via a DFU bootloader. It doesn't impact anything further.

Third - ninja boot-bin in the build directory builds the bootloader, and is the only thing you'd need to use something like st-flash for. However, this is only if you want to use the BMD bootloader and not the ROM bootloader. If you want to use the ROM bootloader, then it's meson configure -Dbmd_bootloader=false then ninja to rebuild (both run from in the build directory). This will give you new binaries that get flashed to the start of Flash, not offset into Flash.

It would be helpful if you would describe the actual steps taken to go from a clone of the source to this failing firmware load on your board and whether your board was blank Flash to start with or this is an attempted upgrade. There's a lot missing to try and help you and if anything it's suggesting a documentation issue leading to user error, not a bug in the firmware. You can remove the -dev packages you installed without materially changing anything. Compiler used for the firmware does matter, so please provide arm-none-eabi-gcc --version.

Hopefully this helps.

[ALTracer]

I missed a step. Meson does not compile the optional bootloader by default. ninja -C build-f411ce blackmagic_blackpill_f411ce_bootloader.bin to force it to do so, or indeed ninja -C build-f411ce bootloader if it's supposed to work via the alias build target. I tried even the simple ninja in builddir and it compiled most libopencm3 targets and BMDA in a minute, but no bootloader.

$ ninja -C build-f411ce bootloader
ninja: Entering directory `build-f411ce'
ninja: error: unknown target 'bootloader'

That should produce a second binary, ~8272 bytes, which you flash any way (AN2606 USART or ST DfuSe) to beginning of internal flash memory; then continue with any instructions for native as-if you've got only BMP Bootloader (do not press BOOT0 button, but you can press PA0 user button which I check in usbdfu.c) Note that meson behaviour differs from Makefiles here. This line produces both binaries. $ make PROBE_HOST=blackpill-f411ce BMD_BOOTLOADER=1 -j4

One more question. What onboard crystal does your device have? It should be 25 MHz. If you bought the newer version with 8 MHz, please state so and it's a separate issue tbh (to build system documentation etc.)

[Ganesharyal24894]

if anything it's suggesting a documentation issue leading to user error, not a bug in the firmware

Yes I too think there is some mistake with the way I am generating the binary rather than the firmware itself. I am trying to do what is shown here (https://github.com/blackmagic-debug/blackmagic/tree/main/src/platforms/common/blackpill-f4). I don't know how but it had worked for me earlier, on my other laptop. The steps that I did were as following and I am flashing it on a blank board, no firmware upgrade :

1. git clone --recurse-submodules https://github.com/blackmagic-debug/blackmagic. git
2. meson setup build --cross-file=cross-file/blackpill-f401cc.ini
3. cd build
4. meson compile
5. st-flash write blackmagic_blackpill_f401cc_firmware.bin 0x08004000

Compiler used for the firmware does matter, so please provide arm-none-eabi-gcc --version

arm-none-eabi-gcc (15:10.3-2021.07-4) 10.3.1 20210621 (release)

ninja boot-bin in the build directory builds the bootloader, and is the only thing you'd need to use something like st-flash for

I am doing this after meson setup build --cross-file=cross-file/blackpill-f401cc.ini (in blackmagic root directory ) and it says error "version.h" not found.

One more question. What onboard crystal does your device have? It should be 25 MHz. If you bought the newer version with 8 MHz, please state so and it's a separate issue tbh (to build system documentation etc

I am sure that there is no problem with the hardware as I had used this exact hardware as BMP earlier.

I will try to do use the other solutions provided in your reply, honestly I do not understand how this works internally I just know how to use it as a tool, in fact I got to know (from what I understand) that it can use BMDbootloader or default STM32bootloader only after your reply so I am pretty sure that the mistake is from my end but God knows how I was able to do it earlier.

[dragonmux]

I am flashing it on a blank board st-flash write blackmagic_blackpill_f401cc_firmware.bin 0x08004000

You must build the bootloader as described above, and flash that - without that there's nothing for the chip to boot to get from the ROM to the firmware, the first 0x4000 bytes of Flash will contain garbage or be all 0xff's, neither of which are useful.

Please use GCC 12.2.Rel1 from ARM, 10 is too old and has terrible codegen which is why the binary size problems.

[Ganesharyal24894]

I still have few questions though, sorry if my questions sound too dumb

1. From what I understand if I am using something like stlink-v2 for flashing my blackpill via SWD then I don't need "src/blackmagic_dfu.bin" to be uploaded to my board right? this is only for flashing the BM firmware via USB?
2. so what I should be flashing at 0x08000000 is, "build/blackmagic_blackpill_f401cc_bootloader.bin" and then the "build/blackmagic_blackpill_f401cc_firmware.bin" at 0x08004000, is that correct? because even after doing this I see the same output which is, "device not recognized in device manager" .
3. what is the role of "src/blackmagic.bin"? I was following this https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c and I see they are flashing blackmagic.bin as well after flashing blackmagic_dfu.bin, is this because the article is old and project has changed since then or is it because they are using different hardware?
4. Where can I read more about the firmware build process for different platforms I find very little documentation on how to get it working with blackpill or anything other than bluepill, there are a lot of documents on how to use it once BMP is up and running, which is good but as a beginner former would be helpful for me

[dragonmux]

1) It's not about how you're loading the firmware on initially, but rather whether you've told the build system you want there to be a bootloader for easier upgrades or not and which flavour of bootloader for platforms that have a choice. The build system tells you where to put the firmware if you're not using the project's own tooling for just this reason as it has nothing to do with how you get to firmware in Flash when provisioning.

2) We would suggest mass-erasing the probe and loading just the bootloader .bin using st-flash, then trying to have it boot - this'll confirm that you have a working USB link and that the bootloader is happy; then use bmputil or dfu-util or \<insert DFU tool here> to get the firmware binary on using the bootloader, which already knows where the firmware should be in Flash and doesn't need an ancillary link to do.

3) That's from the Makefile build system; blackmagic_dfu.bin is equivalent to the Meson build system blackmagic_blackpill_f401cc_bootloader.bin, while blackmagic.bin is equivalent to blackmagic_blackpill_f401cc_firmware.bin.

4) There is detailed documentation in the project main README.md and the platform (src/platform/*/README.md) README.md's along with some documentation on the website (the website does need some love though).

NB: Some of the documentation and guides are out of date simply because we're still working on the v2.0 major version and new guides and documentation has not been written yet owing to a lack of release of the new major and having been focused on fixing bugs found in the process. If you would like to contribute better guides to the website or fix a documentation problem in a README.md that would be most welcome.

[Ganesharyal24894]

I will try to list all the steps that I am doing in as detail as possible just to make sure they are correct, probably someone can point out my mistake here

• git clone https://github.com/blackmagic-debug/blackmagic.git

• cd blackmagic

• meson setup build --cross-file=cross-file/blackpill-f401cc.ini

• cd build

• meson compile (I can see the blackmagic_blackpill_f401cc_firmware.bin after this)

• ninja boot-bin (I can see the blackmagic_blackpill_f401cc_bootloader.bin after this)

• st-flash erase

• st-flash write blackmagic_blackpill_f401cc_bootloader.bin 0x08000000 (after this I can see BMP DFU listed)

• st-flash write blackmagic_blackpill_f401cc_firmware.bin 0x08004000 (after this it starts showing "Unknown USB Device(Invalid Device Descriptor)" )

OR

• instead of flashing via st-flash I tried this sudo dfu-util -d 1d50:6017 -s 0x08004000:leave -D blackmagic_blackpill_f401cc_firmware.bin as well but it shows the same error

Is there anything wrong with my steps? if not how do I debug what is the problem here?

[dragonmux]

That all looks reasonable up until the firmware which brings us back to the same question we asked before about compilers and when talking about codegen - please use ARM's GCC 12.2.Rel1 from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads#panel5a as at this point it sounds like you've got a miscompilation happening.

This is backed by the fact the bootloader runs and is happy (which won't need further replacement at this point, that's confirmed to be functional by the fact you could see the DFU interface), and that USB works via the bootloader confirming a working USB cable and that libopencm3's USB implementation is happy on your board.

[Ganesharyal24894]

Ohh I forgot to mention that I did upgrade the compiler after your recommendation arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009 should I be using specifically the 12.2 version or upgrading to the latest is fine?

[dragonmux]

We're specifically calling for the ARM version, not your distro's, and preferably 12.2 - if you use 13.2 then it must be ARM's version as there are still issues to be figured out with Ubuntu's rather insane packaging of the compiler.

[Ganesharyal24894]

Tried with arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614 and arm-none-eabi-gcc (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205 both did not work for me :( is there any known issue with using WSL? I had done this on my Ubuntu machine and it was working.

[dragonmux]

WSL does not impact on the compilation side of things, only the probe interface. #636 is of note as pitfalls in WSL, but that shouldn't be what you're hitting on. It would be worth checking what Device Manager is saying however in the host Windows environment.

[Ganesharyal24894]

Hey, after flashing bootloader, it gets listed as Black Magic Probe DFU (BlackPill-F411CE). Is it normal that even though I am using a 401cc crossfile it is getting listed as 411CE , is this supposed to happen or could it be a problem?

[dragonmux]

That definitely seems wrong. Please can you check the contents of build/src/platforms/common/blackpill-f4/platform.h, and the output of meson configure | grep probe run in the build directory to verify that the correct probe has been selected in the Meson configuration, and the correct platform configuration written out?

[Ganesharyal24894]

output of meson configure | grep probe in build dir is

  advertise_noackmode            false                            [true, false]
         Let GDB know that the probe supports and prefers
  alternative_pinout             0                                [0, 1, 2, 3]
         Alternative pinout for probe (only applicable to
  probe                          blackpill-f401cc                 [, 96b_carbon, blackpill-f401cc, Hardware platform where the BMD firmware will run
  serialno                       1
         Serial number to report (only applicable to some probes)

and this is what I see inside platform.h

#ifndef PROBE_BLACKPILL_F4_PLATFORM_H
#define PROBE_BLACKPILL_F4_PLATFORM_H

#define PLATFORM_IDENT      "(BlackPill-F401CC) "
#define PLATFORM_CLOCK_FREQ RCC_CLOCK_3V3_84MHZ

#include "blackpill-f4.h"

#endif /* PROBE_BLACKPILL_F4_PLATFORM_H */

it looks correct right?

[dragonmux]

Those are both correct, yes. Please confirm then that running (all from in the build directory) ninja clean then ninja and ninja boot-bin recreates all the binaries, and that running grep F411CE blackmagic_blackpill_f401cc_*.bin gives no matches.

[Ganesharyal24894]

Yep, did it and found no matches

but can still see this

[dragonmux]

Ah, interesting - that could be a cached string. Please check in your WSL environment what lsusb -vd 1d50:6017 gives you in the device descriptor. If it's wrong there that would be very troubling given the string does not appear in the binary you Flashed.

[Ganesharyal24894]

usbipd list also shows the same 411ce in powershell

but WSL environment shows the correct one 401cc

[dragonmux]

lsusb is reading the descriptors and strings direct from the device. usbipd is using what Windows tells it to, and Windows is using a cache in the registry. You can trust lsusb here. You can ask Device Manager to uninstall the drivers for the device and then retrigger detection - we recommend doing that given the issue being seen so as to force it to pick the new strings up properly.

If you put the firmware back on the device now we've been able to verify that, does the issue recreate and even after also uninstalling drivers for the firmware in Device Manager and forcing a rescan?

[Ganesharyal24894]

Although uninstalling and forcing a rescan fixed the listing name : But still after flashing firmware BMP shows this :

[Ganesharyal24894]

Hey, I was trying to do the same thing with the Make build system. Why does the make command only generate blackmagic.bin when used with 'make PROBE_HOST=blackpill-f401cc' and not blackmagic_dfu.bin as well, like it does when used with 'make PROBE_HOST=swlink'? In the former case, should the user just use the blackmagic_dfu.bin generated by 'make PROBE_HOST=swlink,' or are they different for each platform? Also, a small doubt: why do we have both Make and Meson build systems? Is there any scenario where one should prefer to use one of these?

Please don't mind me asking these questions. I am thinking of updating the README or just providing a separate article for converting a Blackpill into BMP. I would move it to Discussions from next time don't want to flood issues section :)

[dragonmux]

The default that was contributed by the users of the Black Pill platforms for the Makefile build system is that the platform uses the ST ROM bootloader by default, meaning, to translate to Meson-ese, -Dbmd_bootloader=false so the binary gets loaded at the very start of Flash using the ROM DFU bootloader for upgrades.

why do we have both Make and Meson build systems? Is there any scenario where one should prefer to use one of these?

The Makefile build system is the old build system and cannot handle BMDA dependencies properly nor the intricacies of switching target support on and off or otherwise handle the much more complex configuration needs of the firmware directly. It's very clunky to use in that way and even clunkier to write. The Meson build system is the new build system (v2.0+) and is written using a tool designed to handle dependencies properly and with capabilities to manage the configuration needs of the firmware far better.

[Ganesharyal24894]

This issue is closed since @ALTracer has already created a PR for better documentation and the issue has been found in this discussion #1907.