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.