Bootloading Atmega328p-pu with USBTiny AVR Pocket Programmer

CrossRoads,

Thanks for the reply. I was starting to think I was alone in the world.
With Optiboot loaded on the chip, I have Uno selected but still cannot successfully load a sketch from Arduio IDE through the FT232R, even though the FT232R shows up as COM4 and COM4 is selected and I can get serial Read/Write through the FT232R on COM4.

When I load a sketch using avrdude, I have to use the "-B 32" or "-B 16" flag, as a "-B 1" setting results in a "initialization failed, rc=-1" error in avrdude.
I don't know how to control these types of options when Arduino IDE uploads sketches, as Arduino is simply using its own avrdude also. I might be wrong, but it seems like if I can dictate the bit clock period when Arduino transfers, that maybe it would work.
Also a question of mine, in general, my COM4 is set to 9600 baud but in the "boards.txt" the uno.upload.speed=115200. Is that a right? I tried to lower this to 19200 but no change.

I'ved only programmed via the IDE, I'll leave the avrdude questiosn to someome with experience.

Also a question of mine, in general, my COM4 is set to 9600 baud but in the "boards.txt" the uno.upload.speed=115200. Is that a right? I tried to lower this to 19200 but no change.

The baud rate a specific bootloader uses is 'hard coded' into the bootloader code, it is not changeable, so the IDE looks at the boards.txt file and uses the baud rate value from the selected board entry in that file for the board selection choice you had set in the IDE.

Lefty

Lefty,

Thanks, but I am a little confused by your comment. Help me understand please.

In my current situation I want to simply sketch-load rather than boot-load. (I'm not sure if there is really a fundamental difference in this designation in the IDE, but my brain is wired to think like that for the moment.) But for the sake of argument, I can do neither from the IDE through my FT232R, so I understand that the issue is likely the same either way.
So when you say "The baud rate a specific bootloader uses is 'hard coded' into the bootloader code", are you meaning that the baud rate a specific device, in my case the FT232R, used for either boot or program loading is hard coded?
Secondly, you said "the IDE looks at the boards.txt file and uses the baud rate value from the selected board entry in that file for the board selection choice you had set in the IDE".
So, is it important that the baud rate listed in the boards.txt match what is hard coded in the bootloader device?

dgrigg123:
Lefty,

Thanks, but I am a little confused by your comment. Help me understand please.

In my current situation I want to simply sketch-load rather than boot-load. (I'm not sure if there is really a fundamental difference in this designation in the IDE, but my brain is wired to think like that for the moment.) But for the sake of argument, I can do neither from the IDE through my FT232R, so I understand that the issue is likely the same either way.

With the present IDE release there are two very different ways to upload a sketch to an Arduino board (or standalone target chip). The first is the way that was always been available in the IDE and that is to use a serial link from a PC com port (or PC USB virtual com port) to a arduino board that has both a USB serial converter chip (either a FTDI or AVR based USB serial converter chip) and ALSO has had a bootloader program burned into the 'target' chip (as all purchased arduino board have). The bootloader that was burned into the chip uses a baud rate value to use that is specific to that version on bootloader. So that is why you must select the board type in the IDE that properly matches the baud rate and board clock speed that the board you attach to the PC.
The second newer method to upload sketches to a arduino board with the IDE is using the IDE file menu option of 'upload using programmer' option. This method uses whatever hardware programmer device you select in the IDE to use the ISP protocol method to burn a sketch into a board that is attached to the hardware programmer. This method because it's not using serial com to talk to the board does not require that their is a bootloader program already installed into the target arduino chip you wish to upload to.

So when you say "The baud rate a specific bootloader uses is 'hard coded' into the bootloader code", are you meaning that the baud rate a specific device, in my case the FT232R, used for either boot or program loading is hard coded?

The IDE tells the PC com port what speed to use when doing a serial upload operation based on the speed that the board selected option tells it to use. The arduino board's bootloader when started at power-up or auto reset expects the com port speed to be at the specific speed that bootloader expects it to be at.
Secondly, you said "the IDE looks at the boards.txt file and uses the baud rate value from the selected board entry in that file for the board selection choice you had set in the IDE".
So, is it important that the baud rate listed in the boards.txt match what is hard coded in the bootloader device?

Yes, it must match unless you are using a hardware programmer that uses ICSP method to burn the sketch.
Lefty

Lefty,

Thanks. This clears up some details for me.
As you explained, the second newer method is working fine for me. However, as to the first method, I bootloaded the optiboot.hex bootload to my Atmega328p-pu which I understand to be the bootload for a typical Uno. I also set the fuses according to the Uno. And I have the neccesary 16Mhz exteranl clock and all.
By doing so, I would assume that selecting the "Arduino Uno" as my board type in the IDE would satisfy the necessary conditions to allow uploading of a sketch to work. This is what I have tried, but fails.
Am I still missing something?

Please confirm you have a 10K reset pullup resistor to +5, 100nF cap between FTDI's DTR pin and the reset pin, and preferably a small diode from reset pin (anode) to +5 (cathode).

dgrigg123:
Lefty,

Thanks. This clears up some details for me.
As you explained, the second newer method is working fine for me. However, as to the first method, I bootloaded the optiboot.hex bootload to my Atmega328p-pu which I understand to be the bootload for a typical Uno. I also set the fuses according to the Uno. And I have the neccesary 16Mhz exteranl clock and all.
By doing so, I would assume that selecting the "Arduino Uno" as my board type in the IDE would satisfy the necessary conditions to allow uploading of a sketch to work. This is what I have tried, but fails.
Am I still missing something?

Does your target circuit contain the needed auto-reset circuitry that the IDE first triggers to force the bootloader to run and listen for a valid upload request? If not you will have to try and use a well timed manual reset switch for the upload to work. When I try and use a manual reset I press and hold down the reset switch, then press upload on the IDE and when I see the compiled sketch size reported in the IDE output window I release the switch.

Lefty

CrossRoads and Lefty,

I think you both are coming to a similar conclusion which I will test.
As previously noted, this shows pretty much exactly my layout http://itp.nyu.edu/physcomp/uploads/arduinobload_wires.jpg except for the screw up in the MOSI line.
On the FT232R I am not using the RTS or DTR line at all going to the Atmega328 chip. However, the Reset on the Atmega328 is pulled to 5V with a 10k and a manual reset button as shown.

Should the FT232R's RST line run to the Atmega328 reset, pin1?
And should I go ahead and add the 100nF cap between DTR and RST on the FT232R?

I think I get it that I have no reset running over to the Atmega328, as it IS running over from my breakout board to the Pocket Programmer, as shown in the image.

dgrigg123:
CrossRoads and Lefty,

I think you both are coming to a similar conclusion which I will test.
As previously noted, this shows pretty much exactly my layout http://itp.nyu.edu/physcomp/uploads/arduinobload_wires.jpg except for the screw up in the MOSI line.
On the FT232R I am not using the RTS or DTR line at all going to the Atmega328 chip. However, the Reset on the Atmega328 is pulled to 5V with a 10k and a manual reset button as shown.

Should the FT232R's RST line run to the Atmega328 reset, pin1?

No, do connect the FT232R's reset pin to anything, just leave it as a no connection.

And should I go ahead and add the 100nF cap between DTR and RST on the FT232R?

No. You need to go from DTR on the FT232R to a series wired cap, then cap to the reset pin of the 328.
Lefty

I think I get it that I have no reset running over to the Atmega328, as it IS running over from my breakout board to the Pocket Programmer, as shown in the image.

Yes, need the reset connections described for software reset during serial sketch download.
Diode keeps weird things from happening with reset button push/release.

OK,
I hooked up a 100nF cap in series from the FT232R DTR to the 328 pin1 Reset. A 10k is still pulling up 328 pin1 to 5V. Still same error from IDE...

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\arduino-1.0\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM4
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: . [00] 
avrdude: stk500_getsync(): not in sync: resp=0x00

avrdude done.  Thank you.

I also added a diode IN4148 from Reset to 5V. Leaving the 100nF cap in series from DTR to Reset and 10k pullup.
Same result.

Are Tx & Rx swapped by any chance?

No, not swapped. Again, I can successfully receive Serial data from the 328 through the FT232R on COM4 onto the Serial Monitor in Arduino IDE. So, they must be correct. Plus I double checked anyway.

Hi,
can some one explain maybe in short, what is actually going on, bootloading arduinos?
2 Usb connections! I finally got it working, but why so complicated?
When I bought the avr pocket programmer I thought thats all I would need, connect it to the ISP connector of the chip e.g.ATmega328P, add a resonator and programm it.
Instead of using an IDE I thought I`ll be using the Arduino Software.

I got it working, but don`t have a clue how.

Thanks for any explainations,

John :slight_smile:

johnguy:
Hi,
can some one explain maybe in short, what is actually going on, bootloading arduinos?
2 Usb connections! I finally got it working, but why so complicated?
When I bought the avr pocket programmer I thought thats all I would need, connect it to the ISP connector of the chip e.g.ATmega328P, add a resonator and programm it.
Instead of using an IDE I thought I`ll be using the Arduino Software.

I got it working, but don`t have a clue how.

Thanks for any explainations,

John :slight_smile:

Well you have paid your dues that's for sure. But as you imply you really haven't mastered the art until you can do it twice in a row separated by six months. :smiley:

Lefty

can some one explain maybe in short, what is actually going on, bootloading arduinos?

The 2 USBs are for 2 interfaces into the memory area.
When you install the bootloader via the ISP interface, the Flash area is being accessed pretty directly by the programmer. Same for File:Upload Using Programmer, when a sketch is loaded and the bootloader is wiped out; the Flash is accessed by the programmer.
When you install sketch via the serial interface, the bootloader is running as a sketch and receiving the data and putting it into Flash.

There is way more detail you can read about in the '328P datasheet, Section 27 and 28.

Thanks,
ll have to look up section 27-28, but I still dont understand, why Im not simply programming the bootloader. Its only a little programm, executing instruction after instruction. I also wonder why this proramm is nowhere to be found, its got to be a .hex file. Ok, there are different ones for different controllers. As far as my understanding on µcontrollers goes, the 328 must receive and give commands over its serial interface through its usb from the Ardu sw, to and through the programmers usb to the programmer, which not only talks back and forth to the Ardu sw, but also flashes the 328s memory with data from the bootloader.hex. So 2 usbs communicating, and the 328 communicates with Ardu sw while being programmed, with data comming from Ardu sw.
Maybe Ardu sw is telling the prorammer where the boot.hex is?
I found out about how to install the bootloader from this source: http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard
Is there any Arduino publication about it? I mean this is so far out, ... I`ve never even heard of anything like it, if someone would have told me, I would not have believed it.
Very complicated.
Thanks anyway

John