Arduino Board Power sources vs. Running program

Windows: I have finally gotten the Arduino USB board running using the ATmega168 with the test LED program. Now, however, I have noticed something strange. The program runs fine when connected to the USB port, but in standalone mode (without the USB cable connected) the program doesn't start. These are the indications I see:

USB power: With reset (or not) the pin-13 LED flashed a couple of times and the program starts blinking pin-13 LED after 8-10 seconds. Good! EXT power: With reset (or not) the pin-13 LED flashed a couple of times when power is applied, but the program (LED blinking) never starts. Both cases: PWR indicator lights just fine. External power 9-12v at ~50 mA.

The only difference I notice is when the USB cable is connected, the TX/RX lights flash a couple of times on power up, and the program runs, regardless of power source.

Does this mean the Arduino board must be connected at all times for ANY PROGRAM TO RUN??? This is not very useful, if the board must remain connected to a computer to function. Advice? Possible causes?

Linux: Separate issue. The Arduino program opens with the open file dialog, shows folders. I can navigate through the folders, but ONLY folders are shown. No files at all. This is perplexing, to say the least. OS is Fedora Core 6 with the same indications on both a 32-bit system and a 64-bit system. This may be operator headspace, but I thought I would see if anyone had experienced this, or what am I doing wrong? Thanks in advance for any input.

Advice? Possible causes?

10k pull up/down on the RX data line. noise is probably causing the bootloader to hang.


Thanks for the lead and quick response. However, that raised further questions. Is that the RX line between the uController/J1 header/FT232BM, or the RX line from the USB port to the FT232BM?

DUH! After looking at the board I "discovered" testing the J1 header RX line would be as simple as sticking a resistor in the header and to ground. That seems to have solved the problem. I am pleased it did, as scraping a copper trace for the USB to connect a resistor would have been a "bit" more difficult. Thanks again for the advice.

Now if I could just figure why the Linux version is not working. Perhaps some missing java jars?

Yeah, you put the resistor in the right spot, on the RX line on the ATmega side. There is more information on this issue in other forum threads (and it was late and I was in a hurry, hence the terse response earlier). Basically if it's allowed to float it introduces noise which can confuse the bootloader.

Sorry, can't help you with the linux questions; I'm running on OS X.


I think it’s asking you to pick a default location for Arduino sketches. Just pick the folder you want.

you know, it's interesting. i had this same problem (and asked about it, but perhaps not as clearly) anyway, i tried pulling rx to ground and this works, but the question i have is... that previously the arduino worked fine, without needing the resistor to GND. but after messing around with attempts to get the software serial working the pulldown resistor becomes necessary. is this a problem with the atmega 168? if i replace the atmega 168 with a new one will it work without the pulldown resistor?

any suggestions will be appreciated. thanks.


we are still experimenting with the ATmega168. We brought the new design out using it believing blindly ATMELs datasheet, and now we are discovering some small issues like this one with the resistor. This is of course affecting the design of future revisions of the boards.


here's a bit of funny info:

1) arduino NG rev.c out of the box - worked fine WITHOUT the 10k pulldown resistor 2) i attempted to get software serial to work with the arduino. suddenly the board would only work WITH the 10k pulldown resistor, even when trying very simple test programs such as the LED blink 3) after some time the board began working again WITHOUT the 10k resistor with sketches that did not use software serial 4) got the software serial working (with help from the arduino forum) but... now the 10k pulldown resistor becomes necessary again.

very odd. but everything now works fine!

David, I used a pull-up resistor instead of the pull-down as recommended in the forum discussions and it works just fine. The AVR has a programmable pull-up resistor in each I/O port, so in my opinion, the best option is to enable pull-up for the RX pin in the bootloader, instead of adding more components to the board. I don't have the NG board, but I do have the serial V2 and the USB boards. I will test the new bootloaders (atmega8 and atmega16) on both boards and send you the results, if you are interested.

Might want to rethink this pull-up, pull-down solution. Here's why...

I've been looking into this problem since I wasn't convinced that it was external "noise" that was causing the problem. I tried different pull-up-down's, but didn't like the idea that I had to disconnect them when going to do a download, so I took a different approach. Since I'm running from a 12V 7AH gel cell, I was pretty certain it wasn't supply noise, and the problem persisted after hitting the reset button, so I knew it wasn't contact noise.

So I went to my trusty junk bin, er, ah, I mean parts box and pulled out a bunch of well aged condensers. I think they call them capacitors nowadays. Anyway, I threw away the pull-up-down resistor and started with a 0.1 mfd cap between RX and Gnd. Hey, that worked! The program now starts 10 seconds after a reset, or after initial application of power. OK, lets see if I can drop the value. Took it in steps from 47 pf back up to 0.1 mfd. At 47 pf, 470 pf and 1000 pf, no help. At 4700 pf the problem was cured. So I built in a little safety margin and put in a little disk cap marked 103 (10,000 pf or 0.01 mfd) across RX and Gnd and called the problem "Solved".

Oh, wait a minute, I need to check if I can still download a program with the cap in place and no pull-up-down resistor (since it didn't work with the resistor in place). Hooked it up to the laptop, disconnected from the gel cell, switched jumpers, and downloaded a program. Woo-Hoo!

Still had one more test. Hooked the board back to the gel cell, but left the USB cable in place. Switched jumpers and again downloaded and started the program. Things are looking good. Now, one last configuration. Removed the USB cable, hit the reset button, and program started in 10 seconds. Looks like its gonna work just fine.

I did a little more troubleshooting and believe when the board is running without a USB connection, noise is being picked up by the RX pin from some source on the board or the chip, because I could reset and let the little bugger sit there for minutes and it wouldn't start, but as soon as I plugged in the cap, it started after 10 seconds. As soon as the cap allowed the crap on the line to go to ground, the chip reset and started the program. My guess anyway.

Bottom line: Put a 0.01 mfd mini cap between RX and Gnd and things should work OK when the board is on either USB or external (non-USB) power. External noise probably isn't the problem. My guess is it's in the 138 chip or the component layout on the board, but I'm not going to look any further, since it's now a one component, permanent fix.


The pin picks up noise because it floats. Pull up/down is the standard way to deal with a floating input.

My instinct is that the capacitor may prevent the device from working properly, especially at higher rs232 speeds. Part of the standard is acceptable maximum line capcitance, measured in pF IIRC, and your 0.1uF sent that through the roof.


I agree, a pin used as input should never left floating. But the RX pin has an internal pull-up... I modified the ATMEGA8 bootloader to enable the internal pull-up resistor and it is working 99% of the time... I am still trying to debug why it still doesn't work for the remaining 1%... it is very difficult, because when I connect an oscope probe to the pin, it is equivalent to adding a capacitor or resistor, so it starts working. I will try with a logic analyzer and/or JTAG (I don't know if it is possible to debug a bootloader with JTAG). I think the problem can be solved with software, rather than hardware.


did you get 100% on rx pin internal pull up resistor tests? What version of Arduino are you testing? Did you test the serial version (different circuitry on rx)?

I'm asking because I'm trying to implement a hardware solution on new Serial Arduino, and it seems to be a good option (100%), but I want to know if the software solution can be 100% too.

Look this: