BMP using a BluePill (New Version- 4/18 Update)

We will use the Blackmagic sources with modifications from UweBonnes repository (I have attached the binaries, you can skip the building from sources).

https://github.com/UweBonnes/blackmagic

He has already made all needed modifications to support BluePill target on bluepill branch. In comparison with the generic st-link target, this version has better arrangement of pins, high speed SWO/SWV, and support for the Led.
Clone UweBonnes’ repository by:

git clone --recurse-submodules -b bluepill https://github.com/UweBonnes/blackmagic.git

Thanks for posting

Having a link to an up to date BMP binary is really important

Why is it not recommended to power the target from the blue pill?

I would assume this is a limitation of the voltage regulator. My first guess would be to pass through the USB 5 Volt from one board to the other.

Otherwise, is it safe to connect BMP and target when they’re individually powered — do you have to take care to connect the grounds first?

The regulator is rated for 300mW power loss max at 25C, this means 300/(5-3.3) = 173 mA, but this is very theoretical because even at this power loss the temperature of the chip will be increased at 0.3W * 333C/W = 125C. To be safe you have to keep the current below 70-80mA (assuming that the chip is original, not a bad clone like most AMS1117)
If you connect the 5V rail you will be safe.

For the BMP itself, I can say that it is very easy to use it for debugging inside eclipse, no need for additional drivers, just gdb.

On Windows, I’m getting something strange happening

The Serial ports are enumerating as Teensy USB (as i have the Teensy IDE extension installed – even thought I don’t have a Teensy board)

VID_1D50
PID_6018

The GDB (Serial) port is enumerating as “Black Magic Trace Capture”

VID_1D50
PID_6018

But is showing up as unknown device

I have not had that issue before.

I could be the Teensy have a conflict with the BMP drivers.

I’ll try to uninstall them

I rolled back my drivers and the 2 GDB and serial ports are now displaying correctly, but the Trace Capture driver does not seem to load

[Slammer – Sat Apr 28, 2018 4:39 pm] –
To be safe you have to keep the current below 70-80mA (assuming that the chip is original, not a bad clone like most AMS1117)

To be even more correct it should be:
“ALL of the AMS1117 bought in China”
The clone AMS is not too bad about 500mA (peak) and I ordered some times ago about 100 PCS for nearly zero bugs as exchange.
On one maple mini (I think I ordered them 4-5 years ago) there was also a little regulator (like on bluepill) instead of a clone AMS. After connecting a simple TFT and some other low power stuff it went up into smoke. So it’s true: I only use the LDO on bluepill for the chip and onboard LED for safety reasons.
Edit: The ST-Link clones are using the same LDO! I think this is (one of?) the reasons why people are complaing about dying ST-Link clones.

@madias, I think even for a simple regulator like AMS1117 there are many clones with different qualities….
I learned my lesson very hard using a “AMS1117″… the damn thing failed and shorted the input voltage to the output…. every chip in my pcb including a small tft display burned!!! I replaced the regulator ( i bought a bunch of them!!!) and made some tests…. no short circuit protection, no thermal protection and after failure the output was shorted to input!

@steve: I think the xxx1117 has no protection at all, like the TS1117 —> http://cdn-reichelt.de/documents/datenb … TS1117.pdf
Rule of thumb (for me): Never put more than 5V to the input of the 3.3V LDO, so even in worst case scenario there is a little chance that some of the components will/may survive.
Edit: ok, the LM1117 DOES: http://www.ti.com/product/LM1117
The LM1117 offers current limiting and thermal shutdown. Its circuit includes a Zener trimmed bandgap reference to assure output voltage accuracy to within ±1%.

UweBonnes’ repository is rebased to blackmagic/master, I updated the binaries…
If you have a working blackmagic, update only blackmagic.bin with the command:
dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic.bin

I just used STLink to flash the DFU part to 800000 and the main application to 8002000

Actually I should get around to using my binary merging tool to make a single bin file that could be flashed.

I’m not sure why the BMP doesn’t have a build target to make the whole thing or perhaps to make it without the DFU updater.

I think that they keep the bootloader separated to support the “self-updating” feature without extra equipment.
I found the dfu bootloader very handy for updating… just a simple command.
FYI the previous version had a problem with STM32F030 targets (my new tiny toy ), now seems to be resolved.

I managed to work with Blackmagic and Eclipse without problems using the generic “GDB Hardware debugging”. Everything works but I am missing the extras of MCU Plugin with OpenOCD Debugging (Peripherals view, etc). Unfortunately with OpenOCD plugin, target have to connect through IP port 3333… and doesn’t accept the target extended remote command to gdb…

I built myself a BMP pill following instructions in this thread, but I had to apply some fixes to UweBonne’s rebased `bluepill` branch, pushed here:

https://github.com/kzyapkov/blackmagic/tree/mypill

I needed the bonus UART, but it didn’t work with TRACESWO enabled, so that’s one of the changes I had to apply. At best, I got TX to work, but no RX from the attached target.

Does this BMP code build for you? Or do you use some prebuilt binaries?

Does your UART work with TRACESWO?

I created a Linux Mint VM to clone and build the latest version using UweBonnes fork but the build fails so I just downloaded Slammers bin files dated 3/5/18 and loaded onto a Bluepill using ST-Link v2 on Windows.
While I had the VM running though I cloned the original Blackmagic git and built the stlink version that I then loaded onto another ST-Link V2 clone.
I have tested both versions (STlink & Bluepill) programming a CJMCU-8223 nRF51x BLE module and with the Bluepill version I also connected the serial debug to the PA2/PA3 pins to keep it all on one module. I have not tested debugging yet but my main reason for doing this was to allow programming the BLE modules
All very nice, thanks for the method/files Slammer.

Hi,
New to STM32 and BMP, appreciate all the hard work that has gone into this project. I do have couple of comments

1. As above I too have downloaded UweBonnes github version, https://github.com/UweBonnes/blackmagic, the “bluepill” branch.
– I am seeing a compile error as well, an undefined “speed” variable in src/command.c. Looks like some junk found its way in, I just deleted the references to “speed”. Compiled on ubuntu v14,04 just fine.
– Loaded the images on the bluepill via Windows 10, st-link and an STM32F3Discovery board just fine.
– SWD debug to an stm32F3discovery seems to be just fine.
– Serial port uart via A2/A3 works fine to an Arduino pro mine
– Have not tried JTag.

2. I do have a concern with the use of A2/A3 for the serial port however. In addition to other changes that may have been brought in with the bluepill branch it appears the SWD/JTAG pinouts were changed from using bluepill “non” 5 volt tolerant pins to using 5 volt tolerant pins, which is a good thing.
However as mentioned in another thread it looks like the serial port is still using “non” 5 volt tolerant pins (A2/A3) Serial 2 I guess. While that probably does not matter for Tx, out of bluepill, it could be a problem for Rx, in, if connecting up to say a 5 volt Arduino pro mini which I believe to be 5 v output on Tx.

I’ve looked at the code some and may at some point poke at it to see if I can move to 5 V tolerant pins but given my newbieness with port mapping/bit twiddling that does not promise to be a near term thing. Has anyone addressed this? Minor yes, I can use a voltage converter, just would be convenient not to.

All that said, i could be talking out my hat. Apologies if that is the case.
Thanks.,

Move it over to USART3 and it will be 5v tolerant.