firmware not working for BMP21 probe.

[abdosalem490]

I have replicated [https://black-magic.org/_downloads/9268bd95a59bf58b68008004df51c31f/bmpm_v2_1c_schematic.pdf](BMP21 schematics) and tried to download the native firmware into it using segger j-link, but it doesn't work. I tried to debug it using segger j-link from the command line, it seems like stm32f103Cb has entered hard fault handler. I tried to build the source code for the BMP21 (I know it's a legacy board) but all the targets I see in meson build are this:

can anyone help ?

[dragonmux]

👋🏼 First off, a point of nomenclature.. what you're wanting to work with are not targets - those, strictly, are the things the firmware supports debugging. You are wanting to build for a specific probe. In your case, native.

Second, without knowing what exactly you tried to load, where, and with what option bytes set.. there's too little information here to be able to help.

You will need to load the project bootloader onto the STM32F103 first, and make sure it enumerates and boots. You can then load the firmware, the firmware does not include the bootloader in the image. You will need to have set the option bytes appropriately for the HW3 platform (v2.1c hardware is hardware ABI version 3) so the firmware can correctly determine what it's running on.

To build the bootloader, you will need to run ninja -C build boot-bin in addition to a normal compilation run which generates you the firmware.

[abdosalem490]

@dragonmux
I am sorry I didn't elaborate on what I am trying to achieve.
I have made the to-be called debugger board for my needs and here is an image of it in the PCB design software:

after I received the board, I soldered all the components onto it and made sure that the MCU USB port is working by writing my own code for it. what I am trying to accomplish now it have the black magic firmware running on it so that I can use this board as a debugger for other boards.

I download the binary file for Stable Release v1.10.2 and tried to download the binary file into my debugger board using a j-link but it wasn't working (doesn't appear under the ports tab in the device manager). I tried older release which is Stable Release V1.6.1 but also, it's not working.
I tried to debug the firmware but it seems like the binary I am trying to download isn't build for stm32f103cb because it seems like it's trapped inside a hardfault handler function.

can you tell what I am doing wrong?

[dragonmux]

Everything in our original reply still applies. You still need to provision the bootloader, and option bytes. The firmware on its own is not sufficient for a from-scratch bringup. It's not about the release chosen, the board simply doesn't have the bootloader or option bytes to start with. We would also strongly advise using main (v2.0.0-rc1) and not v1.10.2 but that doesn't change our advise above.

Bootloader first, make sure that enumerates.

[abdosalem490]

@dragonmux
I am sorry but I am just a noob, I can't find the boot-bin directory, I have seen it mentioned on the official website [https://black-magic.org/knowledge/compiling-windows.html](Compiling on Windows)

I have searched in the downloaded repository and after running the command:
meson setup build --cross-file cross-file/native.ini
and another time after running the command:
meson compile -C build
I got the binary and executable files for the target but no 'blackmagic_native_bootloader.elf' is found.

[dragonmux]

It's not a directory, it's a specific target in the Meson build system - hence telling you to use ninja directly instead of meson compile. ninja -C build tells Ninja to operate in the build directory, what comes after that is the name of a build target [Ninja nomenclature, not project].

ninja -C build boot-bin will make you the bootloader .elf and .bin. Again, this is not a directory or source file, it is the name of a build target.

[abdosalem490]

@dragonmux
thanks a lot, after generating the bootloader binary and downloading it to the hardware, it appeared like this in the device manage:

I still haven't downloaded the actual firmware but I will follow the Firmware Upgrade steps shown on the website.

my question, you said:

the board simply doesn't have the bootloader or option bytes to start with

do I have to configure any options bytes before proceeding ? because I haven't modified any of the option bytes.

[dragonmux]

Yes, you will still need to configure the option bytes so the firmware can know what the hardware ABI is present to properly talk with the hardware. There have been 6 hardware interface versions for the native hardware so far, hence mentioning before which one the v2.1c hardware is.

[abdosalem490]

@dragonmux
I have to apologize for the headache I caused you but I can't find any resources talking about 'hardware ABI version 3', I am trying to search for any keywords telling me what are the configurations used for the options bytes and modifying it, so can you point me in the right direction?

[dragonmux]

What you're looking for is described in the platform.c for the probe:

blackmagic/src/platforms/native/platform.c

Lines 65 to 85 in ab6d92e

	/*
	* Pins PB[7:5] are used to detect hardware revision.
	* User option byte Data1 is used starting with hardware revision 4.
	* Pin - OByte - Rev - Description
	* 000 - 0xffff - 0 - Original production build.
	* 001 - 0xffff - 1 - Mini production build.
	* 010 - 0xffff - 2 - Mini V2.0e and later.
	* 011 - 0xffff - 3 - Mini V2.1a and later.
	* 011 - 0xfb04 - 4 - Mini V2.1d and later.
	* xxx - 0xfb05 - 5 - Mini V2.2a and later.
	* xxx - 0xfb06 - 6 - Mini V2.3a and later.
	*
	* This function will return -2 if the version number does not make sense.
	* This can happen when the Data1 byte contains "garbage". For example a
	* hardware revision that is <4 or the high byte is not the binary inverse of
	* the lower byte.
	* Note: The high byte of the Data1 option byte should always be the binary
	* inverse of the lower byte unless the byte is not set, then all bits in both
	* high and low byte are 0xff.
	*/
	static int platform_hwversion_init(void)

[abdosalem490]

@dragonmux
thanks a lot, I have modified the option bytes accordingly using ST link utility and then download the firmware onto the debugger using dfu-util as bmputil was giving some compilation errors related to DfuLibusb for some reason as in the following image:

Anyhow, firmware was downloaded successfully and it appears as 2 COM ports in the device manager as expected. Thanks a lot, couldn't have done it without you.