I have been using Arduino for a few years now building projects here and there. Currently, I have completed an array of 96 RGB LEDs being PWM'd through shift registers. I have all the arrays completed and completely transferred it from breadboard to perf board. The system works with a traditional store-bought Arduino Uno, but I figured as I am on my 4th UNO and don't particularly like the idea of buying one every time I have a new project, I figured I would build my own!
So, I ordered all the components to build a standalone Arduino, using the ATMEGA328. I successfully built it up on a breadboard, and used the ArduinoISP as a bootloader to bootload the Arduino environment onto the ATMEGA328. It appears to have taken as I get no errors. I also purchased the USB to Serial FTDI Basic ( FTDI Basic Breakout - 5V ) from Sparkfun to program sketches through the USB to my newly bootloaded ATMEGA.
I receive the following error when attempting to upload the Blink sketch to my micro:
avrdude: stk500_getsync(): not in sync: resp=0x00
Now, followed the steps outline in this tutorial ([urlhttp://arduino.cc/en/Main/Standalone[/url]) to build my standalone micro.
I have it wired such that TX of the FTDI Basic goes to Pin 2 (RX) of the ATMEGA, and RX of the FTDI Basic goes to Pin 3 (TX) of the ATMEGA. The FTDI is powered through the USB while the ATMEGA is supplied from an external supply - with grounds connected.
I have researched around and cannot find a solution to this issue. I have read the FTDI Basic has a clock frequency of 1MHZ which causes issues communicating with the 16MHZ clock frequency generated by my crystal for the standalone ATMEGA. Could this be my issue? My standalone arduino that I bootloaded is 100% recognized by Windows 7 and the Arduino Environment under Port 4 - so it is being recognized. I only see the transmit led blink a few times when uploading a sketch, nothing on the recieve LED. This indicates a communication problem to me - possibly related to the difference in clock frequencies?
Any ideas here on what my issue may be? I am 95% of the way there - just having trouble getting the FTDI basic to communicate to the ATMEGA328. Are there any alternatives that would save me some grief? Or any solutions to this problem that anybody has encountered in the past?
Sketch uploading requires the Arduino to be reset. Normally this is done by controlling the DTR signal from the USB/Serial, which is connected to the reset logic of the Arduino. How have you connected the DTR/Reset?
It is possible to manually reset the Arduino to make the bootloader run. You'll have to hit the reset right around when compilation finishes in the UI.
Comments on the picture:
There is no 0.1uF cap from FTDI's DTR to Reset on '328.
There is no 10K pullup from Reset to +5.
There are no 0.1uF caps from Vcc/Avcc/Aref to Gnd.
Add those, it should program ok and work pretty reliably.
I also read that the Arduino Uno, when used as an ISP to bootload your own ATMEGA chips, sometimes needs to have the autoreset disabled by tying a pullup resistor to the Uno board you are using as a bootloader. I did this and tied a 180 ohm resistor to the bootloading board's reset pin (tying it HI) while the target boards reset pin also pulled up with a 10k, connected to pin 10 of the Uno I am using to bootload. This did not solve the issue.
What I did:
I bootloaded the target board again. This time, I removed the Uno's ATMEGA and put the target ATMEGA in its place. This let me upload the blink sketch via the store-bought UNO's UART. Uploading the blink sketch to the target ATMEGA fitted into the UNO's IC socket went through successfully. I swapped the micro's and put the target ATMEGA back on the standalone breadboard and the blink sketch works perfect.
So through deductive reasoning, this tells me bootloading was succesful, but interfacing the FTDI Basic Breakout board was NOT successful. This is at least a start to where the problem lies. I can rule out bootloading as the culprit. I am curious what the other pins of the breakout board are used for, I see two other pins left floating on the breakout board - DTR and CTS. Are these pins verified as not being used? Currently they are floating, and when measured with a DMM all pins read 5v.
Is there a difference between the mini USB and the FTDI cable? I know for a fact my mini usb currently plugged into the breakout board is 100% verified to be data capable (not just charging). If there is a difference, perhaps this is where my issue lies? Maybe the FTDI cable has pinout differences from the standard mini USB?
The issue of not being able to upload sketches appears to be surfacing from my use of the breakout board, which I am still new to. Using the exact same software parameters and an Uno board, I am able to upload the same sketch, to a difference chip.
CrossRoads:
Comments on the picture:
There is no 0.1uF cap from FTDI's DTR to Reset on '328.
There is no 10K pullup from Reset to +5.
There are no 0.1uF caps from Vcc/Avcc/Aref to Gnd.
Add those, it should program ok and work pretty reliably.
I added the components you suggested, I did in fact have the pullup resistor on the reset pin - i had removed it temporarily and forgot to place it back before the picture. I did however not have any of the .1uf caps in any of the 4 locations you suggested. I placed them and first try, the sketch was successfully uploaded.
Thank you very much! What does the .1uf cap from DTR of the breakout board to the RESET of the ATMEGA do? What is its role? I feel this was the determining factor!
The DTR cap and pullup resistor make an RC timing pulse.
DTR is a low level signal - when it goes low, the low goes thru the cap to discharge it and bring Reset low - and then the resistor lets the cap recharge so Reset goes back high and the bootloader can start up.
