Serial stops CPU

I made a custom board using the RP2040, I can upload just fine but Serial.print will stop the CPU when the serial monitor is open. I have used other boards with different CPUs without problems. I can use SPI and Serial1 on this RP2040 without problems so it seems to be limited to Serial aka SerialUSB on RP2040.
I'm using Ubuntu 20.04, Arduino 1.8.16 (same results with 2.0.0 just looks ugly), Arduino Mbed OS 4.0.8 Nano boards, and user is in dialout group.
It may be something obvious that I am missing but I have not found a solution yet.

void setup(){
  Serial.begin(9600);
  pinMode(25, OUTPUT);
  digitalWrite(25, HIGH); // LED
}

void loop() {
  delay(500);
  digitalWrite(25, LOW); // blink 1Hz
  delay(500);
  digitalWrite(25, HIGH);
  if(millis() > 10000){
    Serial.println("a"); // wait 10 seconds then print every cycle
  }
}

LED will blink as long as I don't connect serial monitor or any other serial terminal, also the Arduino serial monitor seems to take longer than usual to open or close, LED will blink fine for the first 10 seconds if serial monitor is opened early. Once closed the LED may blink one more time.
If I comment out the Serial.print line then the LED will blink with or without serial monitor.

Any ideas?

Have you tried with other baud rates?

once millis gets over 10000 this will fire at loop speed..

sorry.. ~q

Which would be once every second. But here it will only fire once and I get (almost) the same result.

bool a =false;
void setup(){
  Serial.begin(9600);
  pinMode(25, OUTPUT);
  digitalWrite(25, HIGH); // LED
}

void loop() {
  delay(500);
  digitalWrite(25, LOW);
  delay(500);
  digitalWrite(25, HIGH);
  if(millis() > 10000 && a == false){
    Serial.println("a"); // wait 10 seconds then print once
    a = true;
  }
}

BUT.... It does start blinking again a little after closing serial monitor.

Yes but whatever speed you use is ignored according to Serial Ports (USB and UART) — Arduino-Pico 3.6.0 documentation

"Serial is the USB serial port, and while Serial.begin() does allow specifying a baud rate, this rate is ignored since it is USB-based."

I am not familiar with your setup.

Does the RP2040 use pin 25 for serial communication?

Maybe if you try using a different pin for the LED…

On the RP2040, Serial is USB serial on pins 46 (USB_DM) and 47 (USB_DP). They have the proper 27 ohm series resistors and TVS diodes going to a micro-USB connector. I can upload the program using this USB port, when using boot_select jumper it shows up as a mass storage device where I can read the INFO_UF2.TXT file or write a UF2 file. I have used 25, 26, and 27 for LED and also no LED, same results. So USB seems to work properly at the hardware level and I am missing something at the software or library level. I did a few more tests with this small change:

#include <stdio.h>
#include "pico/stdlib.h"

bool a =false;
int blinkTime = 500;

void setup(){
  Serial.begin(9600);
  pinMode(25, OUTPUT);
  digitalWrite(25, HIGH); // LED
}

void loop() {
  if(Serial.available() > 0){
    blinkTime = 75;
  }
  delay(blinkTime);
  digitalWrite(25, LOW);
  delay(blinkTime);
  digitalWrite(25, HIGH);
  if(millis() > 10000 && a == false){
    Serial.println("a"); // wait 10 seconds then print every cycle
    a = true;
  }
}

If I connect USB cable and quickly open serial monitor then it stops blinking, but resumes blinking about 5 to 20 seconds later.

If I connect USB cable and quickly open serial monitor AND send a character then it stops blinking, but resumes blinking FASTER about 5 to 15 seconds later.

If I comment out the Serial.print line then connect USB cable, open serial monitor and send a character, close serial monitor, it blinks at the slower rate for another 40 seconds before switching to faster blink rate.

I have tried different computers and different USB cables so it seems to be one or more of: my operating system(s), Mbed OS board library, or missing some important setting or command to handle serial events.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.