Sudden failure of Serial Monitor

Plugged a working Pro Mini into the programmer and got gobbly gook in the serial monitor. (~⸮⸮⸮f) This was working fine yesterday. Plugged in another Pro Mini, same result. Uploads program the Pro Minis as expected. Serial monitor and code in Pro Mini is set to 9600 baud. One Pro Mini is bare, the other is plugged into an expansion board. Nothing is connected to RX or TX except the programmer.

I’ve even rebooted the PC. The LCD on the expansion board prints the code identification strings, so the code is working as expected (except the serial).

I’m looking for setup() to report the currently loaded code:

char this_file[] = "Monitor_2" ;
char descp[] =     "Prints time & volts" ;
char ver[] =       "ver 2.0 03/09/187" ;

#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

#define I2C_ADDR 0x27 

//Initialise the LCD
#define BACKLIGHT_PIN 3
#define En_pin  2
#define Rw_pin  1
#define Rs_pin  0
#define D4_pin  4
#define D5_pin  5
#define D6_pin  6
#define D7_pin  7
LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

// -------------------------------------------------------------
void setup() { // ---------------- Setup() ------------------
    
  Serial.begin(9600); // Start serial communication at 9600 bps
  delay(100) ; // wait for serial to stabilize
// ----------------version message ------------------------
// Send version description test enclosed in a valid "V" format
// This allows the version to be read in the serial monitor, but
// also allows the network to through the message away when the 
// unit is installed in the system.

//  Serial.write(0xAA) ;      //start byte
//  Serial.write("V") ;       //"Version" message
//  Serial.write(0x0A) ;      //line feed
  Serial.println(this_file) ; //file name
  Serial.println(descp) ;     //description
  Serial.println(ver) ;       //version and date
//  Serial.write(0x04) ;      //EOT
//  Serial.write(0x0A) ;      //line feed
// ------------ end of version message --------------------

 // Switch on the backlight
  lcd.setBacklightPin(BACKLIGHT_PIN,POSITIVE);
  lcd.setBacklight(HIGH); 
  lcd.begin(20,4);        // initialize the lcd 
  lcd.home();             // go home 
  lcd.clear() ;
  
  lcd.print(this_file) ;  // put version on screen
  lcd.setCursor(0,1) ;
  lcd.print(descp) ;
  lcd.setCursor(0,2) ;
  lcd.print(ver) ;
  delay(2000) ;          // pause to read
...
...
etc.

Any ideas are appreciated. I assume that if the uploads are working, then both RX and TX are good in the Pro Minis and the serial programmer. I am at a loss.

Serial uses pin 0 and 1. It looks like you are using those pins for the LCD. Change the LCD to different pins.

Don't think so. That code for the LCD is used in many sketches just like that, verbatim. I believe those are definitions used inside the LiquidCrystal_I2C.h to set up the driver chip for the LCD. They are not Arduino pins, they are LCD pins.

But thanks for your input. I did look again at the code.

Then the problem is in the code you didn't post.

Morgan, there is no code in setup() prior to the code that is posted. This is all of it. Now, if I need instruction in the potential conflicts that can occur in loop() that I am unaware of, I am ready to listen. But I remain convinced that code in loop() that has not yet been executed cannot screw up instructions that are in setup(). I am all ears.

Here are the first few bytes that are sent from setup() (received using HTerm.exe):

E6 98 FE 9E F8 9E 86 9E 60 E6 9E 18 E6 66 78 E6 ...

Try setting the Serial Monitor to different baud rates.

When I'm faced with this kind of unexpected behaviour, I go back to the basics. Can you upload blink to the Arduino? Can you upload an equally simple sketch which uses Serial?

Yes, there can be code inside loop() "yet to be executed" which does affect the startup. Static objects, for example.

Hi,
Have you checked in "Tools" "Board" that you have the correct board selected?

If you "Tools" "Get board Info" with your board plugged in what do you get?

Thanks.. Tom... :slight_smile:

With the I2C LCD library I have installed, your code won't compile:

sketch_mar10a:19: error: no matching function for call to 'LiquidCrystal_I2C::LiquidCrystal_I2C(int, int, int, int, int, int, int, int)'
 LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

Why do you specify all those pins? I thought an I2C LCD wouldn't need those. My installed I2C LCD library has this:

LiquidCrystal_I2C::LiquidCrystal_I2C(uint8_t lcd_Addr,uint8_t lcd_cols,uint8_t lcd_rows)

No mention of all those pins which are on non-I2C LCDs.

Pete

Maybe try in the Arduino IDE, tools >> fix encoding & reload?

el_supremo:
With the I2C LCD library I have installed, your code won't compile:

sketch_mar10a:19: error: no matching function for call to 'LiquidCrystal_I2C::LiquidCrystal_I2C(int, int, int, int, int, int, int, int)'

LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);




Why do you specify all those pins? I thought an I2C LCD wouldn't need those. My installed I2C LCD library has this:


LiquidCrystal_I2C::LiquidCrystal_I2C(uint8_t lcd_Addr,uint8_t lcd_cols,uint8_t lcd_rows)



No mention of all those pins which are on non-I2C LCDs.

Pete

Are you using the 16x2 LCD, because that is what the OPs display is by the looks of it?
It looks like you have a different library but same name :o
Tom... :slight_smile:

Thanks, everyone, for all the ideas. I never fail to learn from the community.

I still don’t know for sure what happened. Then I grabbed a "bad"5V one, which “confirmed” the behavior. Then I got a “good” one that functions in the PCB and drives the 4x20 LCD just fine, but it also demonstrates the odd serial behavior. (still accepts uploads just fine, though) At this point I was convinced that something was wrong either with the monitor or the link through the serial programmer (not likely, since uploads were working fine).

I soldered up some new Minis.

Now, with the “new” Minis, the serial monitor is working per spec. So I had 3 bad Minis in a row that all demonstrated the bad serial behavior. I still don’t quite believe that Murphy is that good, but I don’t know what else to blame it on.

Did you always solder the pins to the Mini? It is attractive to just lay them over the pins but that just doesn't work.

Did you always solder the pins to the Mini? It is attractive to just lay them over the pins but that just doesn't work.

Morgan, I don't know what "lay them over the pins" means. I always solder the 0.025 square pins to the Mini boards. All my expansion boards have either stackable headers or plain headers for inserting the Mini pins into.

Even if there was a bad solder joint somewhere, that doesn't explain the serial communication error, since the Mini programmed and then operated as expected.

Maybe I don't understand what kind of alternative assembly method might be used.