Serial.print()s to unconnected USB corrupting i2c?

Have D0/D1 connected i2c to an LCD via an Adafruit backpack. Backpack has 4.7K pullups to 5.0V. Using the Adafruit_LiquidCrystal library. The code seems to work fine, monitored using a bunch of Serial.print() statements when connected to my computer. LCD display works as expected. (It’s reporting thermocouple temperature measurements.)

Now to power the board independently. Using a USB cube wall charger (Apple), tested connecting via either a) the Spark USB cable (i.e. powering to the USB port on the Core) or b) a generic USB cable stripped to connect 5V/GND directly (i.e. to supply power to VIN.)

Starts up fine, reports values for a while, then invariably the display gets corrupted (random characters, characters out of position, etc). At this point, read all the i2c threads on this board.

Seemed to ‘solve’ the problem(s) by adding a bunch of delay(50); statements – but this only worked when 5V was supplied to the USB connector using the Spark USB cable.

When 5V was supplied by a connection directly to VIN, although things started out OK, invariably, after a short or long while, the display still became corrupted.

I had assumed all those ‘Serial.print()’s lurking in the code were harmless, and had left them in. They never seemed to cause a problem in any of the previous stuff I’ve done. But this discrepancy between otherwise identical a) 5V to USB connector (happy) vs b) 5V to VIN pin (corrupted) suggests otherwise. Floating D+/D- issues?

So I deleted all the Serial.print()s in the code. Reconnected to Vin, ran it overnight – everything runs clean as a whistle, no i2c LCD display corruption, very stable.


a) Should I have known to delete my Serial.print()s? Everything else seems to run fine. Is this (i2c corruption) the expected behavior if Serial.begin()/Serial.print()s are left in the code without an actual USB serial connection available?

b) Is there a recommended way to test for an available USB connection for serial output so that I can make my Serial.print()s conditional?

PS. I’m now wondering whether an issue I raised a while ago regarding different HTTPClient timing behavior when connected via USB vs when powered through VIN might be related to my leaving zombie Serial.print() statements in the code, as well.


Some of us have run into I2C issues with LCD displays.

We affected the timing and it worked out… you can see it here.

Yes, thanks, I saw that thread previously, and some of the timing discussion helped. But looking back at it, I realize that this statement, which may be relevant, did not register with me at the time -

The puzzle is that when connected or powered via USB, in my configuration, Serial communication does not cause a problem. But when powered to VIN (USB disconnected), then Serial.print()s do appear to (eventually) lead to i2c corruption.

You could try update to the library I posted on the web IDE and see what happens.

I’m not sure anyone really understood the true cause of the issue, other than affecting the timing made the problem go away.

Giving my dog a treat makes him stop barking… there is still a raccoon in my garage!