I have discovered that plugging my USB into my running Nano close with onboard CH340G causes the I2C signals my Nano was happily pumping out while under external power are killed.... dead
Only unplugging the USB or (unbelievably) re-uploading the sketch causes the I2C to start.
The program keeps running but the I2C doesn't.
I need to be able to plug a USB into my Nano and not kill the I2C... reasonable I think.
Any suggestions? Perhaps there is a routine that can be run in setup() to simulate what happens when the uploader runs? Some other ideas?
How is the Nano powered ?
Maybe there is a glitch when you connect the computer USB 5V to the 5V of the external power supply.
How is everything grounded ?
Maybe the GND of the Nano was floating, maybe it was a high weak voltage due to a cheap power supply. When connecting the grounds, a glitch could stop the I2C.
There is very little in the test circuits as that is what they were designed to do. I'll check later today but I'd put my money on the problem happening when nothing is connected to the Nano except an external power supply and the USB.
I have done this with 5 Arduinos on different circuits and it only happens when the CH340G is used.
Thanks for the link to the other post and I read the links in that post as well.
The reset circuit of the Nano does not contain a diode, perhaps the reset for the CH340G is also not perfect. Perhaps the combination of the Nano and the CH340G is even worse.
My best guess is still a power-grounding-connecting-glitch-thing that travels through the Nano board and disturbs things.
Since you bought a very cheap Nano clone, there might be wrong components on the board. About a week ago someone found that a MPU-6050 module had a 22nF capacitor where a 100nF was needed. The module worked, but not very well. I think you got what you paid for
May I suggest that you buy and official Arduino Nano board ? Or a Arduino Micro board.
I wonder what impact it would have if you disabled auto reset. Put a 10uF capacitor between RST and GND (neg or striped lead on GND). Perhaps also put a capacitor between 5V and GND. Just a thought.
Before I get a chance to try out any fixes I will repost with all the salient points in one place.
The summary seems to be a CH340G controller causes I2C to lock up or at least fail to generate any output when the USB is plugged in unless and until the serial monitor port is opened or an upload is done to the Nano.
Below is the test system plus sketch and photos
Arduino Nano (clone) with CH340G USB controller
Adafruit QUADALPHA display with AdaFruit libraries
Test sketch
Wiring with 4K7 resistor pull-ups on SDA and SCL
Breadboard mounted logic probe on SCL
Salea logic analyser on SDA and SCL
Normal operation:
Sketch loaded
Nano powered from 5v external supply into VIN
Display powered from 5v external supply into VCCand VI2C
Grounds shared with display, logic probe, logic analyser, Nano
Code loops around display and A then a B on the display
The onboard LED digital pin 13 flashes on and off each loop
Debug loop counter output to serial port - USB not connected
Logic probe flashes to indicate changing signal
Logic analyser shows correct output of byte stream with ACKs
Remove QUADALPHA display:
As above except
Logic probe flashes to indicate changing signal
Logic analyser shows output of byte stream with NACKs as expected as device has been removed
The above shows the system working as expected
Plug QUADALPHA display back in:
USB now plugged in:
probe stops, analyser does not see signal, display doesn't change
Serial monitor port opened:
Everything returns to normal operation
Now powered by USB only no external 5v:
No display, no probe signal and no analyser signal
Open monitor or reupload sketch:
Operation returns to normal
Repeat tests with ProMini (clone) and external USB loader with CH340G onboard:
Same malfunctioning results as with Nano
Tests with Uno and Mega without the CH340G show that plugging in the USB does not cause lock ups
#define SYSTEM "ic2ch340g.ino 30/04/2016 11:39"
#include <Wire.h>
#include "Adafruit_LEDBackpack.h"
#include "Adafruit_GFX.h"
Adafruit_AlphaNum4 alpha4 = Adafruit_AlphaNum4();
void setup() {
Serial.begin(9600);
pinMode(13, OUTPUT);
alpha4.begin(0x70); // start the QUADALPHA display
}
void loop() {
static int n = 0;
// used to demonstrate serial output working
Serial.println(n++);
// used to show loop() is looping
if(n%2 == 0) digitalWrite(13, HIGH);
else digitalWrite(13, LOW);
// A to display
alpha4.writeDigitAscii(0, 'A');
alpha4.writeDisplay();
// short delay between display change
delay(5);
// B to display
alpha4.writeDigitAscii(0, 'B');
alpha4.writeDisplay();
// longer delay before next loop to
// make it easier to find output in logic analyser
delay(10);
}
The DTR (Data Terminal Ready) line is used to generate a reset, so one possible reason for the behavior is that the CH340G is activating that line because it's internal serial buffer is full and is not being emptied by the PC as the link has not been established. A schematic of the Nano clone using that chip would be nice but I can't find one...
Put an oscilloscope on the reset line and see what is happening. Narrow glitches on the reset line can cause some parts of the microcontroller to be reset and others to not be reset. In the past I have found clipping on a scope probe fixes a problem like this!
In any event it looks like you will have to live with this behaviour or the quickest solution is to buy some different Nano/ USB serial interface. I have lots of these (>100!) bought from China and none have the CH340G fitted.
If you really want it to work you could try detecting the I2C failure in the code and generating a watchdog reset.
Of course it would be nice to solve this mystery...
I have connected a line of my logic analyser to RST and can see a low going spike when the USB is plugged in and that's when the I2C stops!
These low going spikes are occurring all the time the USB is plugged in and stop when the USB is unplugged and the I2C restarts.
bodmer it looks like you are onto something.
However I don't know how to implement your advice, provided here, in the circuit
bodmer:
So one option is to reduce the pullup resistance values on the I2C bus, hence hopefully make it harder to inject noise on the lines since the line impedance is lower. The display may be using quite a high value of 10K, so try 4K7 on SDA and SCK pulled up to 3.3V.
I already 4K7 resistors on the SDA and SCL
or how to do this in the sketch
bodmer:
This is quite easy turn on the SCK output low, then make it an input so the line is pulled back up, repeat 8 times with say 10uS delays between state changes.
Yep, that is the reset circuit.
The reset is used to upload and that won't work with a larger capacitor at the reset pin, that is normal.
What about a diode from RST to 5V and a lower value for the pullup resistor from RST to 5V. Perhaps 4k7 or 2k2.
I mentioned a power-grounding-connecting-glitch-thing before, and that can still be the cause of the problem. I can reset my Arduino Mega by only connecting the ground of a power supply to the GND of the board. But only in very specific conditions.
Koepel:
Yep, that is the reset circuit.
The reset is used to upload and that won't work with a larger capacitor at the reset pin, that is normal.
What about a diode from RST to 5V and a lower value for the pullup resistor from RST to 5V. Perhaps 4k7 or 2k2.
I mentioned a power-grounding-connecting-glitch-thing before, and that can still be the cause of the problem. I can reset my Arduino Mega by only connecting the ground of a power supply to the GND of the board. But only in very specific conditions.
I don't have any pull-up resistor between RST and 5V unless that is what is on-board. Can I simply add some value resistor between the pins?
You are catching up to what I suggested earlier. Just put a capacitor between RST and GND to disable auto reset. For uploading you can remove the capacitor temporarily, or tap the reset button when the IDE changes from Compiling to Uploading.
You can add a resistor for RST to 5V, it will be parallel to the one on the board. Remove the extra capacitor and try to make it work with a parallel resistor as well, including uploading.
The next question is : how to make the reset circuit more sturdy ? Some boards have been changed for a stronger reset circuit.
The Nano already has a 1K pullup on RST, and that is probably suitable. To prevent auto reset from happening when you don't want it to, it may be good to add a pull down (about 1 to 10K?) on the DTR coming from the CH340G. A pull down on DTR is what the Uno has. And also don't run IDE version 1.6.8 which does that weird serial polling thing. Personally I like just removing the 0.1uF DTR capacitor from the bottom of the Nano to get rid of auto reset, and just tap the reset button during uploads.
I found a schematic here. This suggests the Reset pullup is 10K however most Nano's have 1K. You could check this with a multimeter.
Reducing the 10K to 1K might reduce the glitch but it is not a very satisfactory solution.
If you want a removable solution then you could use the Nano ISP header and temporarily link say 100 Ohms from the RST pin to +5V with a removable header (don't make it too low a value as if you press the reset button the resistor will be connected across the 5V supply).
Other options to fix it will involve more intrusive hacks.
I also note that the 3V3 supply from the CH340 is linked to the 3.3V output pin on the Nano. This is a weak (low current capability) supply so if you are using this to provide power to your circuit then this may be upsetting the CH340 and causing the glitches!
Another potential source of glitches is a switched mode power supply. I have had problems powering Arduinos with some "Wall warts" that generate quite a lot of EMC noise that gets worse depending on the grounding scheme of the rest of the circuit. On one 5V output wall wart I measured 80V (low energy though) spikes and I could feel a tingle from the voltage if I touched Earthed equipment!
Sorry I was vague and inaccurate about that. On the Installation and Troubleshooting section of the forum there have been numerous complaints of the IDE repeatedly connecting to all COM ports every few seconds, and that causes problems with uploads and causes Arduinos to reset frequently (because they auto reset when serial connects). That problem happens with 1.6.8 and some versions of Windows. It's probably not causing your problem.
Your problem was solved in post #8, right? Just manually reset when you want to upload.
dmjlambert:
Sorry I was vague and inaccurate about that. On the Installation and Troubleshooting section of the forum there have been numerous complaints of the IDE repeatedly connecting to all COM ports every few seconds, and that causes problems with uploads and causes Arduinos to reset frequently (because they auto reset when serial connects). That problem happens with 1.6.8 and some versions of Windows. It's probably not causing your problem.
Your problem was solved in post #8, right? Just manually reset when you want to upload.
Re: the IDE polling serial ports - I hope it doesn't do that but it won't be a big issue for me as most of the time I use my own ESM (Enhanced Serial Monitor) for connecting to the Arduinos, of which I sometimes have three on different ports but into the same PC.
Posting #8 basically describes a position that is now workable for development activities and operational activities but the underlying problem isn't actually solved. I find it hard to believe that the issue hasn't been seen before and noted somewhere on the Internet where it could be found again. I'm sure others have seen their I2C dying when the USB plugged in.
I have failed to fix it fully by connecting other resistors, capacitors or diodes but can't say for sure it can't be done. I'd have expected this to have not made its way into production - even for a clone.
I will have to move on next week as this is only a part of a bigger project to stress load a bunch of NRF24s all working in close proximity.
bodmer:
Another potential source of glitches is a switched mode power supply. I have had problems powering Arduinos with some "Wall warts" that generate quite a lot of EMC noise that gets worse depending on the grounding scheme of the rest of the circuit. On one 5V output wall wart I measured 80V (low energy though) spikes and I could feel a tingle from the voltage if I touched Earthed equipment!
I use something more sophisticated for the external power these days since discovering wall warts outputting 18v on a supposedly 12v supply.. POP!
