How-To Guide: Using ST-Link/V2 to Program a BlueSCSI v1.1-a

[BFEXTU]

I finally found my ST-Link/V2 from 2014 and decided to update my BlueSCSI v1.1a (and also program some other BluePills for a build). My ST-Link/V2 is the larger, white unit vs. the small USB dongle.

Initially, for my BlueSCSI v1.1-a, I had no luck direct flashing with the QKM Tools, even though my ROM ended in -USB, etc. I considered trying to screw around with the USB serial driver using Zadig, but then abandoned it in favor of just using my ST-Link/V2.

Getting the ST-Link/V2 set up on Windows 11 eventually worked fine after I figured out what I needed to do.

For others trying to program a BluePill got the drivers and following in my footsteps, here is a simple set of instructions that will hopefully save you a lot of time (that I wasted).

1. Go to ST and get the Windows driver for the ST-Link/V2. Install it and check it in the Device Manager to make sure it's working.
2. If you have an older ST-Link/V2, download the latest firmware update from ST and upgrade your unit. It should work once you have installed the driver.
3. Download the ST-Link Utility installer for your OS and install it. I downloaded the 64-bit windows version.
4. Download the BlueSCSI firmware image you would like to flash. (The latest as of this post appears to be: 2023.11.16
5. Make sure you have the correct USB cable for your ST-Link/V2 unit and at least 5 wire jumpers.
6. Move the yellow BOOT1 jumper (nearest to the rest button) on the Blue Pill to the 1 position to prepare for programming.

For the white ST-Link/V2, the pinouts to connect to the Blue Pill are:

3.3V: Pin 19 (VCC) + Pin 1 (VTRef) -- The ST-Link/V2 expects to sense voltage on Pin 1. So, it MUST be connected to 3.3V somewhere.
Ground: Pin 20
Data I/O: Pin 7
Clock: Pin 9

For 3.3V, I had a double-ended jumper that I connected to pin 19, pin 1 and 3.3V on the blue pill connector.

7. Wire the ST-Link/V2 as above to the Blue Pill 4-pin header. DO NOT connect USB power to the Blue Pill. It is not needed for programming. If you don't have a double-ended jumper wire, just make sure that a 3.3V connection gets back to Pin 1 on the ST-Link/V2 somehow...or solder up a double-ended jumper.
8. Plug in the ST-Link/V2 to USB and launch the ST-Link Utility app. It should see the ST-Link/V2.
9. At this point, assuming everything is correct, you should be able to connect to the target by just hitting the connect button. If you get an error saying that it could not connect to the target, try resetting the Blue Pill. Also, you go to Target->Settings and set "Connect Under Reset." That may help. I had 1 unit that was a little finicky, but I eventually got it to work. You will know that it has connected because there won't be any errors and you will see the app populate with target data and display a green status message.
10. Then, just choose Target->Program and hit start. It should work. If you want to verify the image, I suggest using Verify after Program. I had trouble using Verify While Programming. I ended up getting "internal Command Errors" that I then had to work to bypass -- resets, etc.
11. When you are done, hit the disconnect from target button and unplug the ST-Link/V2.
12. Disconnect the wires and put the yellow boot mode jumper back in position 0.

And that should do it! Well...that is my working assumption. I still have to test my unit and make sure it works.

To load or reflash the bootloader, the steps above are the same, except that you move the yellow BOOT0 jumper (farthest from the reset button) to position 1. Then, you can find the bootloader file here: generic_boot20_pc13.bin. This file looks like an older version of the Arduino boot loader with a similar name: hid_generic_pc13.bin, but I don't know if it will work. Maybe someone else can comment. It does load correctly, however.

Good luck! Hopefully, these steps will demystify the Blue Pill programming. It's not hard. The biggest stumbling block for me, as above, was not connecting VTRef. Without sense voltage the ST-Link/V2 will display "cannot connect" errors.

 

[BFEXTU]

Well...the programming seemed OK - got the 5 green blinks after flashing the bootloader. Then, I loaded the image. The problem may be termination on the Quadra 950. I could only previously make it work on the 900. I guess I will try it on a different machine and see if it loads.

Also, after writing the initial post, I found this page: Using the ST-Link/V2 that says that version that I have doesn't work...but it does seem to work. So, maybe it was just the voltage sense on Pin 1 of the ST-Link that was the issue. Well...I still have to prove that it works and that there isn't just some weird termination issue.

Well...it also did not work on my 8500. I guess I will try a Mac II.

 

[BFEXTU]

@eric I am trying to figure out why the programming doesn't seem to be working. Is there anything in the ST-Link/V2 that I'm missing? STM32 option flags or something? I set the BOOT0 jumper, program the bootloader, then set BOOT1 jumper and program the image. But, it seems like it's not working. I will look at the .bat files again. I think the white ST-Link/V2 is OK -- everything programs and verifies and it has no trouble communicating with the Blue Pill.

Can you help me course-correct? I must be screwing up somewhere. Thanks!

 

[BFEXTU]

I think the programming is working OK. After programming the bootloader and setting BOOT1, I was able to see the Maple USB Serial device. So, I used Zadig to assign a USB Serial driver, then QMK Tools could see and flash OK. So, assuming the latest v1.1a image is good, then the Blue Pill should be good. I will try it again.

 

[BFEXTU]

I got it to show up on the Quadra 950, so everything is fine with the programming, but the drives were not writable because of what seem like termination issues with the Quadra 950. If anyone has any experience using BlueSCSI on the Q950, let me know.

Here is what I see so far on the Q950 with BlueSCSI and termination:
1. It doesn't work unterminated in the middle of the internal bus (0) - it hangs the machine.
2. It doesn't work in an external chassis on the external SCSI port with a black terminator or black terminator + jumpers
3. It does work on an external chassis with just the jumpers and no black terminator, but isn't writable -- generates errors.

(In this case, I don't know if it's termination or power -- so I will go after the Berg connector next.)

[Edit: I solved #3, which I think was being caused by either formatting or mixed SCSI drivers on the same SD Card - it works on the external bus now with just the termination jumpers - see below.]

 

[BFEXTU]

Also @eric , what is the trick for programming the image using the ST-Link Utility or Cube Programmer without going through the USB serial flash process? Is there a different offset, boot config or some other option that needs to be set?

 

[eric]

Also @eric , what is the trick for programming the image using the ST-Link Utility or Cube Programmer without going through the USB serial flash process? Is there a different offset, boot config or some other option that needs to be set?

Flash the non-usb version or flash the bootloader via stlink, then the -usb version via usb. Those are the only two options.

 

[BFEXTU]

Thanks. I got it working with the latest 1.1 firmware after using Zadig to install the WinUSB driver for the "Maple 03" USB Serial driver provided by the bootloader image: generic_boot20_pc13.bin noted above. After that, QMK Tools worked fine. However, I'm still digging into the STM32 docs to see what other insights there might be. I was able to get v1.1a working on the 950 (external bus only so far) using passive termination, no Berg power required, overwrite (SD Formatter Tool) and exFat-formatted (Windows) SDCard and FWB3.0.2 drivers using 2Gb drive volumes. Now, I am trying the partition case on a 10gb fsutil volume (command: >fsutil file createnew [name] [size]).

There were multiple problems. Also, termination for 1.1a on the 950 seems very sensitive. I haven't gotten it to work on the internal bus yet. The voltage was OK. I did try it with Berg power @ 5.12V and that was also OK/made no difference.

Also, note above that the larger, white ST-Link/V2 interface is actually OK. It worked great. It just needs VTRef sense. Also, it won't connect unless either BOOT0 or BOOT1 is pulled high.

 

[BFEXTU]

@eric Do you have any thoughts on why the BlueSCSI v1.1a performance is so slow on the Quadra 950? It doesn't seem able to even clear 1Mb/s. The SDCard shouldn't be an issue and it has been fully formatted. On Windows 11, it sustains writes at ~21Mb/s and reads at ~98Mb/s -- far above Mac rates. The main problem seems to be the access time. 60ms is very slow (see below).

The card must be OK, since SPI is running at 50Mhz -- here is the log.txt info:

VER: 1.1-20231116-USB
DEBUG: 0
SDCard Info:
Format: exFAT
SPI speed: 50Mhz (much faster than the max 18Mhz SPI rate on the STM32)

Theoretically, per the datasheet, the STM32 F103 Blue Pill should have a full duplex SPI max rate of 18 Mbits/s, or ~2.3 Mbytes/s (on the built-in ports). However, Reads are coming in at ~5 Mbits/s (28% of max) and Writes are ~6 Mbits/s (33% of max). That's a lot of overhead somewhere. The STM32 runs at 72Mhz -- but that probably still means that the max is no more than 1/4, considering what it would take to bit-bang on GPIOs. I guess that's why SPI is 18 Mbits/s (or Mhz). The built-in port function may actually be faster/optimized. Even in the worst case, it should be possible to hit 50% of max, or ~9 Mbits/s (9 Mhz, or 1/8th of the processor frequency).

Are you using the built-in 18Mhz STM32 SPI function or GPIO bit-banging?

Comparison of Cheetah vs. BlueSCSI -- both using the same FWB 3.0.2 HDT driver on the same Quadra 950:

Here is my Seagate ST3146707LC 10K Cheetah Drive on the Quadra 950:


Here is my BlueSCSI v1.1a with v2023.11.16 firmware on the Quadra 950:


Apparently, Cheetahs sometimes DO win.

I wouldn't expect BlueSCSI 1.1 to be as fast as a Cheetah drive, but I'm just wondering if there is some other problem or issue since it is far from its theoretical max.

Anyway - interested to know if you have any suggestions on what might improve BlueSCSI performance in my config, if anything. Thanks.

I have also ordered a BlueSCSI v2 and ZuluSCSI RP2040 for comparison and will check out the benchmarks.

 

[BFEXTU]

Adding Berg power to the BlueSCSI improves the access time issue and slightly improves overall R/W performance. 1.5ms access time is good.

So, there definitely seems to be insufficient power via SCSI alone for the blue pill on my Quadra 950. My guess would be that BlueSCSI always needs Berg power, even if it seems to work without it. There are probably current draw issues.

 

[BFEXTU]

Part of the problem may be the generally poor quality of the Blue Pill builds/components and/or counterfeit CPUs. My first Blue Pill ended up with a non-functional USB port after only a few uses (no power). Similarly, the 2nd Blue Pill USB port has power, but won't enumerate without additional manipulation of the connector. So -- very cheap, low-insertion count connectors. The cable seems to be OK with a fresh Blue Pill. I also tried to overclock the one in the above benchmark and it no longer works at 72Mhz. I can flash the bootloader and load images via USB serial, but it no longer correctly recognizes the SD Card -- maybe SPI is blown out. Otherwise, the card seems fine.

I looked around at some of the overclocking posts and nobody reports a destroyed Blue Pill, so I'm not sure why that happened to my unit. Anyway -- my advice would be to not bother with overclocking. It's probably not worth it and if it works, you are just getting (very) lucky. At some point, I will get a couple of replacement ICs and micro-USB ports to (hopefully) return the boards to functional status.

So, 2 dead Blue Pills so far. I'm starting to think the extra tweaking is a waste of time.

 

[BFEXTU]

I put together the pin headers for another Blue Pill from the same batch to get the BlueSCSI working again after the failed overclocking/damage. The performance is similar.

BlueSCSI (Berg-Powered) - Quadra 950 - FWB3.0.2:


The devices are branded as ST, but...? Also, the oscillator appears to be 8Mhz (but I didn't scope it out).

I have noticed a weird/benign boot issue on the Quadra with System 7.5.5. When there are a lot of partitions, not all of them will mount automatically in the Finder unless the FWB startup diagnostics scan runs. So, either there is a starting/mounting issue when using BlueSCSI with lots of partitions or the OS is losing track of them. It could be a not ready/not started issue or maybe something relating to termination. (?)

 

[eric]

There's a lot here - I'll try to unpack.

All bluepills are terrible - that's why we (bluescsi sellers) would buy/test/validate before each one sold - I still have a drawer of bad ones. Markings mean nothing. Honestly in 2024 there's no reason to build a (new) v1 when v2 can be built for just a bit more.

When/why a drive is mounted has nothing to do with BlueSCSI - the OS/driver/etc choose when to mount. I've successfully used BlueSCSI v1 to mount 7 devices many times.

The performance is way under what I'd expect even on a V1. Should be close to double that.

If you haven't, please read through the v1 wiki on troubleshooting/flashing/etc - most of these answer can be found there too.

Side note on my 950 i used a shorter cable internally, but then just used a db25 for v1 hooked up to my zip drive for ease of access.

 

[BFEXTU]

Thanks -- yes, I agree. The Blue Pills appear to be terrible. I have a few left over (and some bare boards) that I was trying get working on the 950. I just have 1 built-up board. I may or may not assemble any others. But, I still have some parts.

With respect to mounting at the desktop, a SCSI drive or partition may not mount for many reasons -- drive not ready, drive not started, termination issues, driver issues, desktop file issues, etc. I am using most of the SCSI IDs on the BlueSCSI on the external bus and it has around 15 volumes on it (including individual drives and drives with partitions -- for testing purposes). There are also multiple partitions on the internal SCSI bus. If the Mac boots without the FWB startup diagnostics with BlueSCSI attached, there are a few missing partitions from both devices. There are around 20 volumes total across both devices.

There is definitely some issue here that seems to relate to the BlueSCSI (because the internal drive/bus works fine without it attached). It might be a termination problem or something else, but I'm not sure I want to spend any more debug time on the v1.1 BlueSCSI.

I agree that the performance is generally poor (I was also expecting at least 1.5Mb/s) and I have been through the trouble-shooting guide. From above, you can see that my SPI speed is 50Mhz. Any other suggestions?

I was previously not able to put the BlueSCSI on the internal bus -- it hung the machine when using it in conjunction with my Cheetah drive. But, now that I know it is fully working on the external bus, I will try again and disconnect the Cheetah to see if the BlueSCSI 1.1 will work any better.

Anyway -- the Blue Pills are poor, there are obviously power-related issues and there may also be termination issues. If a shorter cable improves performance, then the problem likely relates to signal integrity and termination/reflections, etc. Guessing. I will probably just use it on an older Mac that is bottlenecked by the CPU.