Blue Pill as Planned?

[msuffidy]

I just got a Blue Pill STM32 microcontroller board for $10 Canadian. It does not have the headers soldered in yet and the through hole looks a bit dodgy, but I'll assume it is working. It does not USB enumerate. I hear this is typical until the boot loader is programmed. I have a few usb to serial things and a free arduino nano. I was planning on hooking up the usb for power to the blue pill and then somehow connecting the serial rx to tx and tx to rx. Then I was hoping I could program the bootloader by serial as one of the jumpers needs to be moved. Then I expect the arduino ide just needs to be set for that board and it will act the same as a nano. Am I missing anything? This picture is not literally of mine, but is like that.

[gnif]

I just got a Blue Pill STM32 microcontroller board for $10 Canadian. It does not have the headers soldered in yet and the through hole looks a bit dodgy, but I'll assume it is working. It does not USB enumerate. I hear this is typical until the boot loader is programmed. I have a few usb to serial things and a free arduino nano. I was planning on hooking up the usb for power to the blue pill and then somehow connecting the serial rx to tx and tx to rx. Then I was hoping I could program the bootloader by serial as one of the jumpers needs to be moved. Then I expect the arduino ide just needs to be set for that board and it will act the same as a nano. Am I missing anything? This picture is not literally of mine, but is like that.

The STM32F103 series of devices already have a serial boot-loader, the jumper enables this at which point you can use a tool like stm32flash to program it. However I highly recommend you instead get a ST-LINK/V2 or clone and use serial wire debug (SWD) as this will allow you to not only flash it much faster (orders of magnitude faster), but also set breakpoints, inspect variables and step the running code.

[msuffidy]

I did an -ok- job of putting the header on. As always usb in linux says new full speed device, not accepting address, failed to enumerate. This as a green led flashes about 1/2 sec on off. I think this may be normal and I don't know how to interpret it, but I think maybe I have to put the Arduino bootloader on so I can use the USB development link. It may be the case more features could be utilized straight up.

[gnif]

I did an -ok- job of putting the header on. As always usb in linux says new full speed device, not accepting address, failed to enumerate. This as a green led flashes about 1/2 sec on off. I think this may be normal and I don't know how to interpret it, but I think maybe I have to put the Arduino bootloader on so I can use the USB development link. It may be the case more features could be utilized straight up.

Yes you will need to do that, the bootloader in the ROM only supports programming over UART (serial).

[pcprogrammer]

I did an -ok- job of putting the header on. As always usb in linux says new full speed device, not accepting address, failed to enumerate. This as a green led flashes about 1/2 sec on off. I think this may be normal and I don't know how to interpret it, but I think maybe I have to put the Arduino bootloader on so I can use the USB development link. It may be the case more features could be utilized straight up.

Most often there is some test software in the flash. This is what makes the led flash. Some times it comes preloaded with the arduino bootloader, but when it is not recognized by linux then you will have to load it your self first.

Just search with google for how to set it up. Lots of tutorials out there like for example https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=48

But gnif is right with the benefits of a cheap ST-linkv2 clone like https://nl.aliexpress.com/item/1005001621626894.html

[tellurium]

The STM32F103 series of devices already have a serial boot-loader, the jumper enables this at which point you can use a tool like stm32flash to program it.

I might be wrong here, but I think not just F1 series, but all STM32 Cortex-M series have ROM serial bootloader and can be reflashed via that bootloader.

[thm_w]

Just for reference, Black pill costs about the same and has a built in USB bootloader.

https://www.sgbotic.com/index.php?dispatch=pages.view&page_id=49

[msuffidy]

I hooked up the serial and I double checked everything and used 2 different usb to serial adapters. 2 Utilities reported communication problems. So I have to assume there is some kind of problem and I am shelving it for now. It does blink when you load off of flash though so I think it is running to some extent.

[msuffidy]

I think what may have gone wrong is that I connected the headers on the opposite side, which actually makes it easier to solder. I guess I am having that problem of solder through the via to the other side sort of issue so I am seeing if I can get the solder down further into the holes. I thought oh that was the problem, but I think there are actually connections on both sides mostly on the other side though.

[AlfBaz]

Somebody gave me their blue pill to program since they weren't able to get to boot load.

Turns out this particular board must have been using some dodgy chip since there was no boot loader in it as far as I could tell.

It was a while ago so I'm a bit short on details, suffice to say I sussed it out with stlink and it differed to my disco devices

[msuffidy]

Again I seem to be having trouble getting the solder to go down into the holes to the other side. It seems to just want to hang out where it is.

[ozcar]

I suppose you are aware of the potential problem with the USB pullup resistor on those boards?

If not have a look at the last of the "Known issues" here: https://stm32duinoforum.com/forum/wiki_subdomain/index_title_Blue_Pill.html . That site is an archive of the original stm32duino.com site where the "Blue Pill" name originated. You will find similar info in many places now.

I have a few of those boards that I got a long time ago, when there was not much of a problem with counterfeit chips. I can see that I attended to the resistor on those boards, but TBH I don't remember if I actually had any problem with them as supplied. I also don't know if the makers of such boards ever acknowledged that there was a problem and changed the value of the resistor that they were using.

I would not make any assumption as to what, if anything, to expect to be loaded into the chips. I always used STLINK to program them, so another vote for that.

[pcprogrammer]

Again I seem to be having trouble getting the solder to go down into the holes to the other side. It seems to just want to hang out where it is.

When it is a properly made pcb the holes will be plated through and the solder does not need to flow into the hole per se.

Having the headers on the "other" side does not matter as long as the correct pins are connected. Be aware that a TX pin needs to be connected to a RX pin and vice versa.

Just order a ST-link v2 clone and see if that does the job. The remark that it might be a dodgy clone may very well apply, and then the ST-link can be used to identify the chip as well.

I might be wrong here, but I think not just F1 series, but all STM32 Cortex-M series have ROM serial bootloader and can be reflashed via that bootloader.

You are right that, at least the series I know of like F3,F4,F7,H7 have build in boot loaders for serial programming. Some also have USB or I2C, SPI, CAN or what more can be used for programming in their boot loaders.

The F1 series only have the serial boot loader active when the correct mode is selected.

[msuffidy]

I think maybe someone sold someone and then me something they blew already. If that is the case it is a sad waste of everybody's time. I am giving up on this one for now.

[msuffidy]

Somebody gave me their blue pill to program since they weren't able to get to boot load.

Turns out this particular board must have been using some dodgy chip since there was no boot loader in it as far as I could tell.

Could be. Acted like it

[msuffidy]

Oh came across something promising. I DID NOT KNOW ABOUT TTL RS-232 LEVELS, I am using a generic usb to serial converter. I am thinking I can just hook the rx tx pins on a arduino nano to  pins A9 and A10 of the blue pill with both plugged into 2 usb ports and it could even work, since I am guessing the nano is also TTL level. Otherwise I could breadboard some TTL inverter. Sound logical? I also changed R10 from 20K to 2K because some scrap I had here had a 2K. No immediate benefit.

[thm_w]

"I am using a generic usb to serial converter"

Photo or link would help.
If you are talking about a USB cable on one end and DB9 on the other, then yeah that is not TTL, and possibly could damage the device you are connecting it to.

[msuffidy]

If you are talking about a USB cable on one end and DB9 on the other, then yeah that is not TTL, and possibly could damage the device you are connecting it to.

Yup. I am thinking what could work is the arduino and stm would basically reside on the same uart. If the arduino stays quiet, I think I can get away with using the nano's usb/serial converter. I think if I hit some command code in the binary upload I could get a response from the nano. I am going to try it soon. Hopefully I did not damage the stm yet.

[msuffidy]

I am not getting any new results from what I attempted. I am a bit confused now. Maybe the nano is inverted?

[msuffidy]

Well I guess I will never know if it works unless I come across a ST-LINK. I will just put it back on the shelf again. From what I have read a good number of knock offs do not inherently serial program, but do ST-LINK.

[msuffidy]

I am wrapping it up but I could have tried to make a converter myself. I was going over some stuff I have here. I have this 74HC00 for example. I was reading the data sheet. If vcc was 3.3 volts would the output be 3.3vots? I think you could tie 2 nand gates at both inputs together as 2 lines, and would that for example invert the signal and output 0-3.3 volts?

[DavidAlfa]

As adviced, a ST-link is a much better option, will allow you to debug the code in realtime when you get used to it.
Otherwise just get a cheap usb-ttl converter like CH340, pl2303, FT232... they're everywhere.
Read:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4020196/#msg4020196

[geggi1]

I just started playing with Bluepill STM32 boards a few weeks ago.
Had a bit of hassle before I got it working.
To help others I have made this description on my Wordpress to help others.
https://geggi73a.wordpress.com/

[msuffidy]

I was thinking about it and I was sort of naive because the TTL serial is actually inverted RS-232 at a different level. So you can't just share a line, because someone will be setting it high, I guess whoever has the TX would be doing that. So the arduino thing was not going to work, but you can actually do that with a arduino original apparently and hooking ground to reset makes the chip offline. Either that or you can remove the chip from the socket. Anyway, I was waffling on it and there is a pretty good deal in town right now to get this arduino starter kit for $20 near where I live. So later tonight I was going to pick it up and see btw if it works. I would be elated to see it worked, but I did a lot of messing with those pine and I very well could have maxed it myself.

[msuffidy]

OK my final results are in. spoilers no it didn't program.

So I got the arduino starter kit for $20 Canadian no tax by way of taking a walk for about 150 meters. I consider it way more valuable than what I paid for it. It is this one which is pretty extensive:

https://www.aliexpress.com/item/32620337494.html

OK so I started trying to use it as a usb to ttl converter by jumpering the reset and ground. It did not flash. I then carefully removed the chip and it also did not flash. What I noticed is in a terminal program any key I would push got the same weird character back to me so I don't know if that means its (stm32) UART is ok or not. Also I would get a 'device not recognized' error the first time I try to use flash demonstrator. The second time it hangs. I notice if I press reset on the stm32, it always gives me the error message like it went further for some reason otherwise...
>>So my conclusions are I think it has a non desired rom code, or it is damaged. For now I am giving up on this one for real.

Here is a photo of the setup

[pcprogrammer]

Looked at the video to what it is about in using the arduino for usb to ttl serial and the reason why he is connecting the micro controller reset pin to ground is to disable it. There is either a CH340 or one of the other USB to serial converters out there on the board. And this one is used to do the communication with the target device. Might be even the same USB to serial chip on your other adapter you tried.

But now you have a nice Arduino kit to play with

[msuffidy]

There is either a CH340 or one of the other USB to serial converters out there on the board.

Yes the idea is to connect the existing usb to ttl converter chip to a new chip. I am pretty sure I did it right and it did not result in solving the problem. Anyway, I was hoping I could get the $10 stm32 working because it was a bit of a new experience. I probably hurt the uarts with non ttl inputs. Possibly a st link can program it, but at least the uarts may be damaged. It may still have clone issues.

[pcprogrammer]

Depends on the voltages. The UART for programming the STM32 is 5V tolerant, so any TTL levels based USB to serial device can be used for it. When it was an USB to RS232 device with +/- levels (believe up to max +/-15V according to specs, but most often +-/-12V) then it can damage not just the UART but also the chip itself.

When you do want to get into the STM32 devices the ST-Link is a good investment. It makes things a lot easier.

[ozcar]

From what I have read a good number of knock offs do not inherently serial program, but do ST-LINK.

I have not heard of that before, but then I never tried to do USART serial programming. I would have thought that if there was such a difference, that it might be useful for distinguishing fake chips, but I don't even recall something like that being mentioned in that regard either (not that that is an area I have been watching closely).

I decided to try it myself. Among the Blue Pill boards I have, I located one that passes the diagnostics (https://www.eevblog.com/forum/microcontrollers/announcing-bluepill-diagnostics-v1-62/), and one that fails (both actually have 128k flash, but the second one reports that via the flash size register).

Well, it turns out that I can tell the two boards apart when trying USART serial programming, but I could not program either of them using that method.

Using the Windows GUI STM32CubeProgrammer, and my most trusted USB - TTL converter, neither board would connect. The definite fake one either responds with a 0x1F nack or does not respond at all.

The one that passes the fake check gets a lot further. A few times STM32CubeProgrammer asked if I wanted to disable memory read protection, said it has successfully done that, but still did not connect.

Neither board has any problem when programmed using a STLINK clone - that is how I loaded the diagnostic code into them. 

[msuffidy]

With mine, I have 3 test sort of programs. STM32Cubprogrammer for linux, stm32flasher from github, and FlashDemonstrator for windows. All 3 of them fail to program through serial. I am a little confused if you can or can't make an arduino into a st link. There is not an abundance of info on it, but seems to be about SPI which looks maybe doable.

[ozcar]

... my most trusted USB - TTL converter

It turns out that my trust was misplaced.

The converter I was using is primarily an AVR programmer, that also includes a USB-TTL converter. I found that the serial converter on this is permanently locked to 8 data bits, no parity and 1 stop bit ("8N1"), while serial programming the F103 requires even parity ("8E1").  The STM32CubeProgrammer allows the parity to be selected (not sure why, perhaps other STM processors are different), but this setting was being ignored.

I changed over to using a CH340G-based converter, and confirmed that with this the parity setting when the port is opened does get honoured.

Now the STM32CubeProgrammer connects to the Blue Pill board with the genuine (or less obviously fake) processor. However, it still will not connect to the Blue Pill with the fake processor.

I'm just a little bit surprised that there would be such an obvious difference in the fake. I had a bit of a look at the bootloader code, and was thinking of duplicating part of that to see if I can work out why it does not work. I'm more interested in this as another way to distinguish between genuine and fake processors, but who knows, maybe I will end up managing to get the serial programming to work.

[msuffidy]

When I hooked up the usb like real rs-232 I noticed that the power light went out on the stm32 if it was connected after the usb serial was. I interpret this as something so electrically weird was going on that it actually did this. It may have been a reverse flow due to a negative voltage. It is not that big of a deal at this point. I just gave it a hard battle to try to get working. I did rough up the stm32 pretty bad by now, but I could have allowed it to be used for some weird little application like steer a rc car or something. I was hoping it would be like a prototyping thing.

[msuffidy]

OK I GOT IT WORKING!! spoilers I reworked all the solder joints and used the arduino uno with the chip removed to program it. I should also add there may be a need to actually press the reset button once which I started doing recently because an example video was doing it.

Ok so I started with thinking it is a CH32 clone chip so I got their programmer, no dice. Then I shorted the jumper resistor as also mentioned no dice. Then I took 1 last look and said, well maybe it is a solder short or connection problem so I reworked them all and it did program and I saw the first life out of it. Now usb recognizes it.

[msuffidy]

This is the final setup. Note there are only 2 wires even involved here.

[pcprogrammer]

Congrats on sticking with it. With the two wires it will only work if both the programmer and the target are connected to the same USB ground, otherwise it won't work.

[msuffidy]

So a day later and I was trying to practically use it. I found that there is this issue going between DFU and ACM usb modes I have not solved yet. I thought I messed up the bootloader, so I went to do it again over serial. To my horror it was not working properly again. So after like 2 hours of testing I came to the conclusion there is some kind of enhanced sync when you press the reset at a proximate time to the cube programmer connecting. Like maybe mine is compromised. So I was brushing stuff on the board and I guess I compromised the R10 replacement I had tried earlier. I wound up messing up R10 and though it was the end. Then I looked at the schematic and the board and used a DVM. It seemed the pull up resistor is like this. It comes off the main line. It crossed to the other pad and then goes into the board through a via. I tested and the via was continuous for 3.3v. So in this case you can just get the same effect by putting a resistor that would be the R10 between edge pin A12 and 3.3V. I tested a few and the 3.x K one seemed to be the most reliable. So it sort of still works quite bashed up. A bit unsafe at that R10. I hope it is in bounds.

[msuffidy]

Here is it now. ewww. Also it only worked at 38400 and 57600 (the ttl serial flash) Also I tested the reset ground method instead of removing the atmega and that also worked.

[msuffidy]

So what am I doing wrong?

[msuffidy]

Well it works in Windows with that stduino boot 20 generic pc13 bootloader, the dfu driver, and the arduino IDE with stm. Too bad the linux version does not seem to work, with the same bootloader. But at least my first blinky is up an going now.

[ozcar]

You seem to be making some sort of progress.

I not sure which STM32 core you are using as there are several variants. I use the "official" STM version (https://github.com/stm32duino/Arduino_Core_STM32), but I sorta think you might not be using that one? At least, the info on the bottom line of the Arduino screen-shot you posted shows settings I'm not familiar with, which I think is not totally due to differences between Windows and Linux.

When using the official STM core, I can select from 7 different upload methods, including two Maple DFU ones. As I mentioned before I normally use STLINK, which is selected there as STM32CubeProgrammer (SWD). I tried now using USART serial upload,  selected there as STM32CubeProgrammer (Serial). That worked for me too, but of course that requires changing the BOOT0 jumper and resetting the board.

I also tried loading one of the variants of LeafLab Maple bootloader on one board, but uploading failed with some Java exception. I suspect this might be due to something else messing with my Windows path, but I don't think I can be bothered with trying to sort that out as I have no need for it.

If you are not using the official STM core, maybe you could give that a go? Otherwise you could try asking over at stm32duino.com.

[msuffidy]

Well I think the point is there is 2 modes for the usb serial. One is DFU and the other is the serial link for comm between the computer and the STM32. There is supposed to be a certain method to switch between them that does not seem to be working in linux. There may be a utility to make them swtich. Also there was another bootloader called hid- something that I tried and it potentially worked in linux. Long story but I erased the chip and put it back and it did nothing, so I thought it needed probably certain ST blocks of default stuff to be on the chip so that kind of freaked me out and I stayed away from it.

Thsi is the video I followed and it did work, just doing it in Linux didn't which was the peril of the last 2 nights:

[msuffidy]

Got it working for Linux. More like they did but maybe it is a bit broken. What started it was I was looking around in the windows DFU driver package to see if there was something else in there that could be useful since it changed from ACM to DFU mode. I found the tools folder that seems the same thing as the one from the Arduino STM32 F103 addon. So I experimented with replacing the Arduino ones with the DFU driver ones. I fist noticed that it found the DFU device if you increased the delay in the script from when it reboots as DFU and when it starts the programming. Also I noticed it could not actually access the USB device. I questioned if that was do to not running as root. Or you know a permissions problem. So it does work if you run Arduino as root. I just copied my .arduino15 from /home/msuffidy to /root in this case. I tried to revert to the original files, but there seems to be a glitch and the DFU driver ones work. I think it could be some options passed to dfu-util. BTW before potentially the successful manner of doing the serial programming was using 38K or 56K and then releasing the reset button on the stm at the same moment the cubeprogrammer started to wait for a connection.

[ozcar]

It appears that you are using the "Roger" core. I have not used that for a long time, and I do not remember if that gives you choice of upload method from within the Arduino IDE.

There are some subtle and not so subtle differences between the different cores, but at the simple level of blinking a LED all the cores provide the same basic functionality. Unless you have a very good reason to use the Roger core, I would suggest that you try the official STM core that I mentioned before. That has support for way more processors and boards than any of the other cores, and over on stm32duino.com there are STM employees to help solve any really tricky problems. You will get some limited support for the Roger core there too, but the recommendation these days there seems to be for beginners to go with the official core.

With that official core, you get a choice of upload as in the image below. That screen shot is from Windows, but it looks much the same under Linux. Yes, I actually installed it on Linux just to see. I did not actually try to use the various upload methods on Linux, but maybe that will work for you without any messing about.

I can't point you to a video telling you how to install the official STM core, but it would be very much the same as what you have done, except that under Preferences, Additional Board Manager URLs you need this: 

https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json

Then in the Board manager, look for and install "STM32 MCU based boards    by STMicroelectronics"

Maybe you have to get rid of the other core first - I'm not sure about that.

And, just for the record:

Now the STM32CubeProgrammer connects to the Blue Pill board with the genuine (or less obviously fake) processor. However, it still will not connect to the Blue Pill with the fake processor.

I found the reason for that, and it was nothing to do with any difference between genuine and fake processors. Rather it was dodgy soldering on the board with the fake processor! The BOOT0 pin was basically left floating so regardless of the jumper settings it was not possible to get the bootloader to run.

[msuffidy]

I put up a video that goes over my experience



If I can't do something I will re consider but it seems to be a solved problem at this point.