Arduino ATmega1284p bootloader

CrossRoads:
I connect it because the Promini has the CTS pin grounded.
The FTDI Basic connects the CTS header pin to the FTDI CTS pin.

So, used or not, that's the way I connect it, and I never have problems with USB/Serial interfacing.

Grounding it will not cause a problem, but it is not a requirement, it will work equally well unconnected, that was my only point.

Lefty

Yes, thats right, I have caps on both sides (0,1µF). On my FTDI there os GND, CTS, VCC TXD RXD and DTR. I thought DTR is the auto reset pin so I connected DTR to Pin 9 with a 0,1µF cap.

This is my FTDI programmer: http://www.ebay.de/itm/230820610037?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649#ht_500wt_1414

Again, thanks a lot for your help!

Is there anyone who have an idea what is wrong?

php-freak:
Yes, thats right, I have caps on both sides (0,1µF). On my FTDI there os GND, CTS, VCC TXD RXD and DTR. I thought DTR is the auto reset pin so I connected DTR to Pin 9 with a 0,1µF cap.

This is my FTDI programmer: http://www.ebay.de/itm/230820610037?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649#ht_500wt_1414

Again, thanks a lot for your help!

First you can use either RTS or DTR as the arduino IDE/AVRDUDE pulses both signals to generate the auto-reset pulse. The oldest auto-resetting arduino boards used RTS, all the newer ones use DTR, but for legacy backwards compatibility the IDE pulses both RTS and DTR signals.
Second, what do you mean by "I have caps on both sides (0,1µF)" ? if the DTR (or RTS) signal has to pass through two series .1ufd caps to get to the reset pin on the avr chip then that is an effective capacitance of .05ufd and may be too small a value to allow the pulse to generate the reset. If that is the case remove one of the two series connected .1ufd caps from the circuit.

Lefty

Thank you for the info, I didn't know that RTS and DTR works.

I made a better picture with a higher resoultion and some description: 2,8MB Picture

I have two caps between VCC and GND (AVCC and GND). And there is one cap between Pin 9 (Reset) and DTR. I checked TX and RX, at first it was correct then I swap them so it wasn't correct anymore so know it is the right way but the error message is the same: avrdude: stk500_getsync(): not in sync: resp=0x00

The programmer is set for 5V?

You didn't say how you were able to install the bootloader.
I install it via the the IDE, Tools:Burn Bootloader.
This ensures that the fuses are all set correctly for 16 MHz crytsal operation.
I download sketches after that.
If the fuses are not set correctly, the data rate for serial downloads will be mismatched and the download will not work.

I selected the Mighty 1284p, 16MHz using Optiboot as board and Arduino as ISP as programmer.

This is wrong for downloading general sketches, it's only used to download the ISP sketch into
the 1284P to use it to program other chips.

Secondly, as Bob asked, how did you burn the bootloader into the 1284P chip in the first place?
Are you sure that went correctly?

Thirdly, your FTDI cable looks like a knockoff of the FTDI friend. It may or may not "in
fact" be using DTR, rather than RTS. If it's actually using RTS you need to go to the
Control Panel device manager for the COMPORT and select "set RTS on close".

Fourthly, it looks like in your 2.8MB picture you have TX and RX wired wrong. The TX
and RX labels on the FTDI Friend and regular FTDI cables specify the signal flow with
respect to the cable, not the Arduino. So, the wires have to be swapped between the
2 devices. BTW, I always insert 1K series-Rs in the RX,TX lines in case I hook them
up backwards.

The other thing is I use the FTDI Friend and FTDI cables most of the time, and have
never tied CTS to anything.

Thanks for the great answers!

I changed the setting in the device manager, just in case to test it. I used this tutorial: Gammon Forum : Electronics : Microprocessors : How to make an Arduino-compatible minimal board and the Serial Monitor said that it was successful. That do I have to choose to download a general sketch?

Yes it is a cheap FTDI version, on the ebay page they said it uses DTR. Thanks for the information that I have to swap TX and RX. Is connection via the cap to the reset pin right for DTR?

For a general sketch, you just go to your sketchbook or the IDE "File > Examples",
and choose something other than ArduinoISP.

I think your reset pin wiring is ok. All you need is a 0.1 uF cap from FTDI DTR to the
1284P reset pin, plus a 10K pullup to 5V on the reset pin. Simple.

I am still curious [Bob too], as to how you burned the bootloader into the 1284P in the
first place. ???

Yes I am, how was the bootloader set up?

I use an Atmel AVR ISP MKii. I use the IDE to burn the bootloader first to make the fuses are set correctly.
The times I forgot to that, I spend a frustrating 1/2 figuring what is going on, eventually figuring out the clock is really slow, and then finally remembering to do the bootloader for the fuses. Getting better about that.

I then use File: Upload Using Programmer with the MKii if I don't need the bootloader, or I connect up an FTDI Basic for downloading sketch via serial interface.

I don't use the Optiboot 16 MHz tho, I always use Bobuino so Serial is at D0/D1, SPI is D10-11-12-13, and I2C is A4/A5 of D18/D19, just like on a '328 board. I like a little consistency.

I don't use the Optiboot 16 MHz tho, I always use Bobuino so Serial is at D0/D1, SPI is D10-11-12-13, and I2C is A4/A5 of D18/D19, just like on a '328 board. I like a little consistency.

The version of bootloader you use shouldn't be effected by the unique pins_arduino.h file you set up to support your Bobuino board. However the entries for the Bobuino entry in the boards.txt file do have to reflect which 1284 bootloader you use, the normal one, or the Optiboot one, as that is where the fuse definitions and top of memory size values are, and they have to match the bootloader you are going to use. It's all pretty interdependent and lots of room to get it wrong. I struggled getting my 644P chip setup correctly and even had to revert to using the bootloader and boards.txt entry for a 644P from my old version 11 Sanguino files, but it all worked out in the end. Still waiting for the 1284P chip to arrive.

Lefty

oric_dan(333):
For a general sketch, you just go to your sketchbook or the IDE "File > Examples",
and choose something other than ArduinoISP.

I have an simple test sketch with serial data to check that it is working so i dont use a special one I just choose the Optiboot 16MHz as board. I set up the µC how it was mention in the tutorial, upload the optiboot code to the arduino and finally use the serial console to send the command to the arduino uno to burn the bootloader. it returns that this was successful.

I had some time today and built a bootloader shield. To test it I take a brand new 1284P and burn a bootloader on it. This is the log:

Atmega chip programmer.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x97 0x05
Processor = ATmega1284P
Flash memory size = 131072 bytes.
LFuse = 0x62
HFuse = 0x99
EFuse = 0xFF
Lock byte = 0xFF
Clock calibration = 0x8D
Bootloader address = 0x1FC00
Bootloader length = 508 bytes.
Type 'V' to verify, or 'G' to program the chip with the bootloader ...
Erasing chip ...
Writing bootloader ...
Committing page starting at 0x1FC00
Committing page starting at 0x1FD00
Written.
Verifying ...
No errors found.
Writing fuses ...
LFuse = 0xFF
HFuse = 0xDE
EFuse = 0xFD
Lock byte = 0xEF
Clock calibration = 0x8D
Done.
Type 'C' when ready to continue with another chip ...

I will post a log with the fuses of the other chip which I am trying to programm later.

By the way this is my bootloader shield: View Image (3,3MB)

I show this because I haven't seen anything similar.

EDIT:

This is the log of the µC we are talking about. Again, thanks for your help.

Atmega fuse calculator.
Written by Nick Gammon.
Entered programming mode OK.
Signature = 0x1E 0x97 0x05
Processor = ATmega1284P
Flash memory size = 131072
LFuse = 0xFF
HFuse = 0xDE
EFuse = 0xFD
Lock byte = 0xEF
Clock calibration = 0x4F
OCD Enable.............................. [ ]
JTAG Enable............................. [ ]
Enable Serial (ICSP) Programming........ [X]
Watchdog Timer Always On................ [ ]
Preserve EEPROM through chip erase...... [ ]
Boot into bootloader.................... [X]
Divide clock by 8....................... [ ]
Clock output............................ [ ]
Bootloader size: 1024 bytes.
Start-up time: SUT0: [ ] SUT1: [ ] (see datasheet)
Clock source: low-power crystal.
Brownout detection at: 2.7V.

Hello,

is there anybody who has another idea whats wrong with my setup?

I appreciate your support!

So what happens after you burn the bootloader - you are still not able to download sketches via an FTDI module connected to Rx, Tx, DTR, +5, Gnd?

Might have to wait for NickGammon to get back from his vacation. You can try to PM him, he has some internet access.

What is the problem now? I thought you had the bootloader burned correctly.
All the fuses/etc stuff should be taken care of automatically so you shouldn't
need to worry about it.

In my case, I just loaded the ArduinoISP sketch into a UNO and told it to burn
the Bobuino bootloader into the 1284, and didn't worry about fuses or anything.

Could this problem related to the one mentioned from this post and the following ones?

I had a lot of problems, then I solved using a non-scientific method: an RC filter, suggested here on AvrFreaks' forum.

Sorry for my late reply I was busy the last week :frowning:

Do you have a like for a suitable rc filter? My problem at the moment is, that the FTDI programmer blinks but I get still error messages :frowning:

As pito figured out, set that low fuse to full-swing (0xF7) in the programmer sketch:

// ATmega1284P family
  { { 0x1E, 0x97, 0x05 }, "ATmega1284P", 128 * kb,   1 * kb,
        optiboot_atmega1284p_hex,
        0x1FC00,      // start address
        sizeof optiboot_atmega1284p_hex,       
        256,          // page size (for committing)
        0xD7,         // fuse low byte: external clock, 0xD7 = FULL SWING
        0xDE,         // fuse high byte: SPI enable, boot into bootloader, 1024 byte bootloader
        0xFD,         // fuse extended byte: brown-out detection at 2.7V
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

Hello.
I had this problem one year ago . The solution for me was to reset UC manually (connect rst & gnd for about 3 seconds) when IDE completes compiling and starts uploading .
Sorry for my bad English.