[SOLVED] Blue Pill Serial Upload: BOOT0==0 causes crash on reset

Hi, I have a blue pill stm32f103c8t6, putting BOOT0 to high, I can upload any program, for example
void setup() {
Serial.begin(115200);
}
void loop() {
delay(1000);
Serial.println("hello");
}

Blue Pill: http://wiki.stm32duino.com/index.php?title=Blue_Pill
From the Wiki on API: http://wiki.stm32duino.com/index.php?title=API

Serial & USB Serial
Serial USB is enabled for all F103 boards when uploading using the bootloader, it is also available when uploading by ST-Link (SWD) In these cases:

Serial.print(“Hello world”); will print via Serial USB (CDC).
Serial1 prints to hardware USART 1
Serial2 prints to hardware USART 2

When uploading via “Serial” (external USB to Serial adaptor connected to PA9 and PA10 (USART1) on the STM32):

Serial.print(“Hello world”); will print to hardware USART1 (the one the code was uploaded using)
Serial1 prints to hardware USART 2, etc

Note: Some boards, e.g. Nucleo F103RB have special serial mapping, because these boards need to have hardware modification to make Serial usable.

The Serial <-> USART mapping is defined in file “variants/<board_name>/board.cpp”.

I don’t undetstand the point, I use PA9 & PA10 to upload the program, also I use the same port to print, it works but the program crash when I return BOOT0 to LOW and then press reset button(only crash the serial port)

I’m more of a Maple Mini – USB guy.
Maybe some of our Blue Pill uses will recognize the issue you are experiencing. I changed the title to better reflect the issue.

Ray
Global Moderator

What exactly means “crash the serial port“?
Which serial port? Serial 1? Or USB serial?

What means “the program crashes“?
Does the LED blink?

Please show us a simple sketch to reproduce your problem.

“crash the serial port” means that the sketch works (because print “hello” in any serial monitor) but when I return BOOT0 to low and then reset, stops the print
“the program crashes” means the same
with blink I haven’t problem
with serial, it works, but when I return BOOT0 to low and then reset, the program stops and print nothing, please you can try with
void setup() {
Serial.begin(115200);
}
void loop() {
delay(1000);
Serial.println("holaq");
}

Combine the two programs – add blink to your serial test.
int LEDPIN=PC13;
void setup()
{
Serial.begin(115200);
pinMode(LEDPIN,OUTPUT);
}
void loop()
{
static int ledState=0;
delay(1000);
Serial.println("holaq");
digitalWrite(LEDPIN, ledState);
ledState = 1 - ledState; // toggle ledState
}

yes, the code hasn’t crashed completely but the serial still does not work

In that case, go ahead and enable the other serial ports.
Serial.begin(115200);
Serial1.begin(115200);
Serial2.begin(115200);
Serial3.begin(115200);


Just an FYI.

I just tried a blue pill under Linux Mint 18.3 and it performed as expected. I used a very cheap USB-Serial adapter.
ray@EliteBook-8570p ~ $ lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 1bcf:2c03 Sunplus Innovation Technology Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 013: ID 0403:0000 Future Technology Devices International, Ltd H4SMK 7 Port Hub / Counterfeit FT232 Serial (UART) IC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Sketch:
/*
BlinkNcount for Maple Mini by m. ray burnette. Compiled on LInux Mint 18.3 w/ Arduino IDE 1.8.5
Sketch uses 9620 bytes (14%) of program storage space. Maximum is 65536 bytes.
Global variables use 1984 bytes (9%) of dynamic memory, leaving 18496 bytes for local variables. Maximum is 20480 bytes.
Turns on an LED on for one second, then off for one second, repeatedly.
Counts and displays the count on the attached serial monitor
Blue Pill example to send test to all serial ports
*/

int n = 0;

void setup() {
// initialize the digital pin as an output.
pinMode(LED_BUILTIN, OUTPUT);
// Initialize virtual COM over USB on Maple Mini
Serial.begin(9600); // BAUD has no effect on USB serial: placeholder for physical UART
Serial1.begin(9600);
Serial2.begin(9600);
// wait for serial monitor to be connected.
while (!Serial)
{
digitalWrite(LED_BUILTIN,!digitalRead(LED_BUILTIN)); // Turn the LED from off to on, or on to off
delay(100); // fast blink
}
Serial.println("Blink LED & count Demo");
}

void loop() {
digitalWrite(LED_BUILTIN, HIGH); // set the LED on
delay(500); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // set the LED off
// Serial.print("Loop #: ");
n++;
Serial.print("Serial: ") ; Serial.println(n);
Serial1.print("Serial1: ") ; Serial1.println(n);
Serial2.print("Serial2: ") ; Serial2.println(n);

delay(500); // wait
}

What you are seeing is not a crash. Its simply that your program is not running….

You can’t leave BOOT0 High and reset the device and expect it to run the sketch

Pulling Boot0 high locks the device into waiting for Serial upload as soon as its powered up.
There is no timeout on this internal feature of the STM32F103… It will wait for ever for upload.

The reason the program runs after you upload is because the uploader automatically executes a Run command after the upload is complete.

[RogerClark – Mon Mar 19, 2018 2:13 am] –
What you are seeing is not a crash. Its simply that your program is not running….

You can’t leave BOOT0 High and reset the device and expect it to run the sketch

Pulling Boot0 high locks the device into waiting for Serial upload as soon as its powered up.
There is no timeout on this internal feature of the STM32F103… It will wait for ever for upload.

The reason the program runs after you upload is because the uploader automatically executes a Run command after the upload is complete.

Roger,

Op is setting BOOT0 correctly … see his 1st post.
…but, when I return BOOT0 to low and then press reset, the program crash…

Best as we can tell is that the LED blinks but serial com is not displaying. Hence my sketch to output on all serial ports as a test. I repeated what I understood rsc had done, but I am getting exactly what I would expect. Process of elimination… next is to validate his board settings.

Ah.

OK.

In that case this is the problem on my Ugly board

It only works if I upload and won’t run if I have boot0 Low

I’ve no idea whats wrong with it, and suspect its a hardware fault, potentially the main / external crystal oscillator is not starting up correctly and the core does not have a way to deal with lazy oscillators. i.e it just waits in a while loop for the main osc to start up.

I’ve seen some code which has a timeout on this, and if the osc doesnt start up in a few thousand loops of waiting, the whole MCU is restarted in the hope that a warm start will allow the osc to run.

However I’ve never bothered to investigate if thats whats happening.
Note the Serial upload feature uses the internal RC oscillator, so the main crystal oscillator can be really lazy and you can still upload.
(I recall one or two people had issues where the main osc would not start at all, but they can still install the bootloader via serial etc)

I recommend that the OP throws the board away, because even if we did track down the issue the board is likely to be unreliable and the osc may some day fail to start at all

Assuming that you use USB serial, because Serial is mapped to USB serial.

After pressing reset the PC will close and then re-enumerate the USB serial port so that the previous session will be disabled.
You will not get any character in that window anymore.

You have to close that window, wait till the PC re-enumerates the port (one or two beep sounds) and only then open a new serial monitor window in order to get new characters shown.
This is normal operation of the system, not a bug (ok, neither a feature).

Steve

As far as I can tell they are using an external USB to Serial connected to PA9 and PA10 to upload, while Boot0 is high

But from what Ray says, if they put boot0 low it does not run the sketch after power on.

I think its a faulty board, (problem with the crystal oscillator, and the core does not have a retry system for crystal osc startup )

Roger, I think that the HW is ok, since the LED blinks:

[rsc – Sun Mar 18, 2018 9:11 pm] –
“crash the serial port” means that the sketch works (because print “hello” in any serial monitor) but when I return BOOT0 to low and then reset, stops the print
“the program crashes” means the same
with blink I haven’t problem
with serial, it works, but when I return BOOT0 to low and then reset, the program stops and print nothing…

but I may misinterpret something.

[fredbox – Sun Mar 18, 2018 10:01 pm] –
Combine the two programs – add blink to your serial test.
int LEDPIN=PC13;
void setup()
{
Serial.begin(115200);
pinMode(LEDPIN, OUTPUT);
}
void loop()
{
Serial.println("holaq");
digitalWrite(LEDPIN, !digitalRead(LEDPIN)); // toggle LED
delay(1000);
}

Steve

I’d completely remove the call to Serial.Println for a “blink” test

I suspect the OP is not giving the full information, or just that he has an unreliable board or perhaps problem with supply voltage etc

I’m not sure why the OP doesnt use the bootloader.

Things don’t make sense with this whole thread.

[rsc – Sun Mar 18, 2018 10:41 pm] –
yes, the code hasn’t crashed completely but the serial still does not work

@rsc: did you try closing the serial monitor and re-opening it after reset? If I’m not wrong the serial monitor hangs in some cases..

Fortunately the problem was stupid, I selected STM32F103R series instead STM32F103C series
thanks you all

[rsc – Tue Mar 20, 2018 9:09 pm] –
Fortunately the problem was stupid, I selected STM32F103R series instead STM32F103C series
thanks you all

. Bet you will never do that again. The only “worst” thing is being initiated into the Magic Smoke Club and watching your precious littl’ uC clock its last cpu cycle.

http://stm32duino.com/search.php?keywords=Magic+smoke

Ray