Posted on Leave a comment

Serial USARTs On STM32 Blue Pill With Arduino Code in PlatformIO

Here’s the “Hello World” edition of getting access to USART2 and USART3 on an STM32 Blue Pill in PlatformIO using the Arduino framework.


/* lib_deps = NONE
  # Using a library name

-------- Platform.ini Settings----------
[env:bluepill_f103c8]
platform = ststm32
board = bluepill_f103c8
#board = bluepill_f103c8
framework = arduino
upload_protocol = stlink
lib_compat_mode = soft

*/

#include "Arduino.h"
HardwareSerial Serial2(USART2);   // PA3  (RX)  PA2  (TX)
HardwareSerial Serial3(USART3); // PB11 (RX)  PB10   (TX)

void setup() {
Serial.begin(19200);   // PA10  (RX) PA9 (TX) 
Serial2.begin(19200);  // PA3  (RX)  PA2  (TX)
Serial3.begin(19200);  // PB11 (RX)  PB10   (TX)

Serial.println("Serial: 1");
Serial2.println("Serial2: 2");
Serial3.println("Serial3: 3");
}

void loop() {
Serial.println("Serial: 1");
Serial2.println("Serial2: 2");
Serial3.println("Serial3: 3");
delay(1000);
}
Posted on Leave a comment

STM32 Blue Pill ADC Values Too Low in PlatformIO

 

I kept getting values that were way too low when feeding an ADC on the STM32 Blue Pill 3.3V. I should have been getting values that were around 4000 and instead I was closer to 800.

Solution
1) The default ADC in the Arduino library is set to 10-bit resolution. This is what you normally get with analogRead(). To change it, put this in your setup(). Read more about it here: https://www.arduino.cc/reference/en/language/functions/zero-due-mkr-family/analogreadresolution/

analogReadResolution(12);

Notes
— This would have been a much easier problem to solve if i had been getting values of around 1000. It turns out that my ADC pin wasn’t getting exactly 3.3V. There was a voltage drop in my system – I’ve got a huge mess currently hooked to the Blue Pill – that knocked it down to around 3V. Normally, calculating bit resolution in decimal is 2^x – 1. So 2^10 – 1 = 1023.

— PlatformIO had nothing to do with the error. I’m new to PlatformIO and never know if my issues are due to the STM32’s specific needs, the Arduino library, or some kind of PlatformIO specific issue. It seems that as long as the hardware is setup correctly and
#include <Arduino.h>
is at the top of the program/sketch/whatever, PlatformIO has no ill effects. The problems I have had aren’t the fault of PlatformIO but from adapting libraries intended for AVR to STM32F1.

 

Posted on Leave a comment

Genuine STM32 Blue Pill vs CS32F103C8T6 Clone

I’m troubleshooting a synth design and looking at the data on the SPI bus.  I have 10 STM32 clones (CS32F103C8T6) of the STM32F103C8T6 around and decided to try them out since they have the correct USB resistor.

I was getting the following error in PlatformIO.

Warn : UNEXPECTED idcode: 0x2ba01477

To get the clone to work, I had to change stm32f1x.cfg which I found in C:\Users\YOUR_WINDOWS_USER\.platformio\packages\tool-openocd\scripts\target\

I changed set _CPUTAPID 0x1ba01477 to set _CPUTAPID 0x2ba01477.  If I need to go back to the real Blue Pill, I’ll have to change this back again.

I started with the clone and then switched to the real one.  The scope shows some interesting results.  This is data from the SPI bus.  The circuit is 100% identical in both cases.

CS32F103C8T6 Clone SPI Data

Genuine STM32F103C8T6 SPI Data

I’m not sure if the clone just can’t handle the speed or if there’s some kind capacitance slowing it down.  Regardless, the SPI output of the clone is so bad that I’ll have to check the timing diagrams for my SPI-receiving chip.  I don’t have this problem with the genuine STM32.

If anyone knows a solution to get the clone to behave, please tell me.  Otherwise, I’ll have to view these Chinese clones as WAY too expensive once time is factored in.