I've been using a 1 wire temperature sensor to send temperature data over serial via my arduino and using usb power. Last night while logging the arduino started flashing pin 13 led and rxtx leds rapidly and wasn't producing any output over serial and on trying to reprogram I got an avrdude stk500_getsync not in sync error, these symptoms seem to say (from looking at other posts) the bootloader is probably corrupted.
What I was really wondering is could large ripple in the USB power supply be to blame?
I'm using the arduino attached to a sheevaplug on which I've measured the usb voltage as 5.12v with a ripple of 300mV with occasional spikes upto +/- 200mV, which seemed very high when compared to my pc (4.93v with 40mV ripple). Also I've experienced brownouts before when using the sheevaplug with arduino.
Would a few capacitors on the usb power rails help solve this (after I've reloaded the bootloader)?
I don't think that'd be a problem.. but one thing I'm curious about, is does the Sheevaplug send information back to the Arduino at any time? In the case of a Brownout (reset), if the Sheevaplug is sending information to the Arduino over the Serial connection, the Arduino might interpret that as the computer trying to program it. ( I believe the chip listens for a '0' or a '\0', not 100% sure)
BUT, this doesn't solve the brown out problems.. do you know what the Sheevaplugs USB plug is capable of outputting in terms of current? I'm guessing it's at least the 500ma, but you never know. Plus, what do you have connected to the Arduino logging data? Some sensors and LCD's take a good amount of current, more so the Backlights for the LCDs but something to take into consideration.
If you rule out the power issues, then I suggest trying without the bootloader, or the "ADABOOT" bootloader. Basically, it will only enter the Boot loader state when the Reset button is pressed, and not when you get a Brownout. It's compatible for all the chips that the Arduino is compatible with. http://www.ladyada.net/library/arduino/bootloader.html
The few times I did corrupt my bootloader, the RX and TX lights stayed off.. but I also wasn't using any Serial communication in the sketch, so that could be a factor! But yeah, the LED for pin 13 stayed on, almost as if it were flashing really fast.. not just a HIGH signal. Resetting the board gives the same results.
One thing that's worth checking out though is your sketch. I know for sure each time my bootloader was corrupted, it was my sketch. I could recreate the bootloader corruption multiple times with the same sketch, I believe it was an error with some sort of memory.. it was while trying to use PROGMEM. There's also some bug about pointers and them wreckin the bootloaders?
I'm sure somebody with a bit more experience with em will come along, I can only speak from personal experiences, and what I've read, of course!
The sheevaplug can supply up to 700mA to its one usb port so that shouldn't be a problem.
I'm using on DS18B20+ 1-wire temp sensor and writing the output of it to serial, no communication computer>arduino only arduino>computer.
I read about sketches corrupting things too, as my sketch was so simple (although using OneWire and DallasTemperature.h libs) I had almost ruled out that as I've seen no other mention of any problems with them.
The reason I suspected power is that I read on the ardupilot site that some people have reported bootloader corruption after power spikes and I'd seen the sheevaplug usb power to be noisy.
I am currently testing the same sketch with another chip and ok so far (4.5hrs) the last one lasted about 6hrs.
I've grabbed a few screenshots from my oscilloscope to show the normal power glitches, these are about every 20 microseconds, and from the sheevaplug there is sometimes one twice the height every several tens of minutes, but I haven't managed to capture one yet.
PC:
Sheevaplug:
On looking at those I'm not sure if it would affect anything or not, adding a capacitor removes the ripple as expected.
Are your scope tracings at the arduino's VCC pin or with no load on the plug? Have you tried sticking in a 4.7uf cap? USB devices are not actually supposed to put big caps on the supply so they don't cause transients when you plug them in.
What kind of arduino is it? On a simpler design like the RBBB the standard power supply caps would be on the line as well as the arduino's decoupling cap. The duemilanove hs more complicated power switching.
It was a duemilanove, the trace is of the no load voltage of the usb port, and yes I have tried a cap on the power and it makes a huge difference (ie it gets rid of the ripple) my question was more asking is the ripple likley to have caused the problem?
How are you connecting your scope to the circuit? Using the ground wire on the
probe will not work when you measuring signals in the 10nS range. The loop
formed by the ground lead acts as pickup for radiated noise.
To remove noise you want to place your cap close to the noise source and use
the shortest leads possible. As bill2009 mentioned there are limitations to the
amount of capacitance you are suppose to load the USB bus with. IIRC when
you initially plug a USB device in it is not suppose to draw more than 100mA and
not have more than around 10uF of capacitance (can't remember the exact cap value).
You might want to search this site for bootloader and USB problems. IIRC there was
was a bootloader issue where receiving serial communications during bootup
would cause the bootloader to hang and flash the LED.
Yes I was using the probe ground as you suggest I shouldn't however the amplitude of the signals shown is greatly above that of noise.
There is no serial communication from the computer to the arduino at any point, it just stopped working randomly at one point and I'm not not able to boot the chip with or without usb connection but it does power up and load a sketch but the verification fails.
Anyway I've had another chip with a working bootloader testing exactly the same situation and it's been ok for the last 4 days now and there have been no problems as yet.
I have read many posts on different things that cause the symptoms I've got but there doesn't seem to be any hard and fast idea of what causes the problems, just many situations that occur in very specific circumstances.
I'm going to reflash the bootloader on the chip and then try again (when my programmer arrives) , if there are no problems in the future I guess I'll just never know what caused this, it's just annoying that's all.
It can be difficult to adapt the methods for an existing design. A couple of ideas --
** Wrap the excess ground lead around the probe. This reduces the loop area
and the impedance.
** Solder jumpers to the board. Remove the probe sleeve and wrap one lead
around the sleeve the other around the tip.
