VSCode cortex-debug BMP support

[perigoso]

Stumbled upon this comment while browsing the cortex-debug extension repo, it might be worth getting in touch with @haneefdm as they appear to be the current maintainer, and having first-class support for BMP is certainly desirable

[haneefdm]

I tried to help before, and will be glad to help. Anyone can edit our extension and make it better for BMP. I was sent a BMP HW but with no cables or anything that works with my ST-Nucleo boards. They don't have a 10-pin debug connector. I have a PSoC6 from Cypress which does have one but not supported by BMP.

In fact, I have no idea where the BMP probe is now in my house.

If I cannot use the BMP probe at all, I can't help.

[perigoso]

There are a couple of adapters to help connect the BMP to an arbitrary target:
0.1in Pin Header JTAG Cable
20Pin JTAG Adapter Board
JTAG/SWD 0.1in Breakout Adapter Board
I'm guessing you didn't get them with your kit? maybe @esden can help with that

You can always cut a cable if you have extra and can crimp headers, though I suspect you don't, either way I'll leave the pinout here

[esden]

The nucleo boards make things quite hard. The built in ST-Link programmer is wired in a way that makes it tricky to connect a different programmer. You have to make sure power is not provided to the ST-Link and then connect the external programmer over the ST-Link connector or directly to the GPIO pins of the target MCU. The alternative is to put Black Magic firmware onto the ST-Link MCU that is built into the dev board.

For tool development purposes, I recommend finding dev boards that provide at least an unpopulated ARM-Cortex debug connector. This makes it much easier to juggle multiple debuggers and targets. There are plenty of Adafruit boards that have that feature. Or alternatively the classic big 20 pin JTAG connector can be found on Olimex boards. Blue/Black Pill boards expose the programming pins too, which makes it easy to at least access the SWD interface. There is no adapter needed, just a flywire cable.

For the first solution referencing their schematics for the dev board are needed to make sure that all that is needed is the ST-Link pin header. The 7pin adapter from us is pin compatible to the ST-Link connector. If that is not enough the flywire cable is a good choice to hook up directly to the respective GPIO.

If you decide to reprogram the ST-Link to Black Magic Probe you don't need to figure out the wiring, but you will have to compile the firmware. Also the reprogrammed ST-Link does not have all the features that BMP has, which might make work on the VSCode plugin harder, as you won't be able to test everything. It is important to support the special monitor commands providing access to target power controls for example. This is something you won't have with the reprogrammed ST-Link.

I hope this helps. Let me know if you have more questions.

[haneefdm]

Thanks @esden @perigoso

The intersection of the boards I have and BMP is zero. I wish someone who has all the equipment can pitch in to help. I don't have the BMP anymore (can't find it anyways). Don't want to say this, but I have physical limitations in being able to solder or making cables, etc.

The alternative is to put Black Magic firmware onto the ST-Link MCU that is built into the dev board.

It sounded interesting until I read the later part that the FW would not be full features and I would have to compiler it myself.

I am not even sure what the current problems are. Anyone who enables our gdb traces can figure out what we are doing wrong.

Finally, if I don't even know what the current issues are, not sure where to start.

[sorrowed]

I know this is a somewhat old thread, but i have been experimenting with the BMP and a STM32 G474 Nucleo board (https://www.st.com/en/evaluation-tools/nucleo-g474re.html) which does come with a built-in 10pin jtag/SWD header: it actually works pretty well.
The only thing i can't get working is Segger RTT on the BMP: I recompiled the BMP firmware with RTT supoprt but the cortex-debug probe doesn't seem to support it on the BMP yet.
Is there anything i can do to help implementing that?

[rijesha]

RTT works for me alright. You just need to have a prelaunchcommand.
{
"name": "Debug",
"cwd": "${workspaceFolder}",
"gdbPath": "",
"executable": "",
"request": "launch",
"type": "cortex-debug",
"servertype": "bmp",
"interface": "swd",
"device": "STM32F103",
"BMPGDBSerialPort": "${config:bmp_serial_port}",
"preLaunchCommands": [
"monitor rtt enable"
]
},

[sorrowed]

@rijesha See below, wanted to reply to you.

[sorrowed]

Hmm, that's weird. For me, its not even opening the RTT terminal like it does with the JLink:

I also (for both BMP and JLink) have to manually specify the address of the control block:

Not sure whats going on tbh.

[sorrowed]

Oh my, you are right. When i do a cat /dev/ttyACM1 the RTT output is right there.
It's the link to the internal terminal then (which is not automatically opened like the JLink server does) which i not working i guess.
In that case, i do not even need the prelaunch/rttConfig though, i just start an external terminal on that virtual port as im not using the cortex-debug plugin for RTT at all.
Thanks a lot.

[dragonmux]

You'll still need the pre-launch (but not the rttConfig block, that was never required) so that RTT gets enabled. mon rtt en is there to tell BMP you want to use RTT and to lock onto the control block, which it will do automatically.

[sorrowed]

Okay, i understand why i have to enable RTT on the BMP side with the prelaunch instructions. What i don't understand is why there is no RTT terminal opening in the plugin like it does when i use the jlink serverType (although i can use RTT with an external terminal so there is a workaround which is great )
Also, when i do add the rttConfig block and use "address:"auto" i get a diagnostic message that the RTT control block cannot be found? Thats why i added the address manually.

[dragonmux]

That's a question for the Cortex Debug project and related extensions as that's all on them as to how they've integrated BMD. If they introduced a config item for the secondary serial interface and handling for when it's in RTT mode vs when it's a serial interface with the target vs when it's in debug mode, that'd be grand, but that's a feature request there - not here.

[sorrowed]

Ofcourse you are right, i'm barking up the wrong tree here. Thank you for the help.