Thanks to Nick Gammon's blog http://www.gammon.com.au/forum/?id=11637, I successfully burned the bootloader on to my 1284P. Since my ftdi cable is en route, i thought i'd burn some programs using my arduino dumilanalov. I removed the atmega328, and took pins from
RX(arduino)-- TXD0(pin15),
TX(arduino)-- RXD0(pin14),
RESET(arduino) -- RESET(pin 9),
5v--5v,
GND--GND
to the 1284p which is on a breadboard.
Then i tried burning a simple sketch.
int led = 3;
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH);
delay(1000);
digitalWrite(led, LOW);
delay(1000);
}
I got the following error message when i used AVRISP mk||.
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x62
avrdude: stk500_cmd(): programmer is out of sync
You need to swap the RX and TX lines over if you are trying to use the built in FTDI chip. (RX means the 328p's RX pin, which means that is the FTDI's TX pin).
Image is correct connecting TX to TX and Rec to Rec. However I don't see any connection to the auto-reset circuit from the arduino to the 1284p chip, so the arduino IDE has no way to initate a auto-reset for the 1284p chip to start the bootloader at the proper time. A simple jumper from the arduino board's reset pin to the 1284p reset pin should fix that situation. Try that and let us know how it works.
You may have to also remove the reset pull-up resistor on the 1284p chip as there is already a reset pull-up on the arduino board and having two in parallel may be too low a resistance for the auto-reset pulse to pull the signal low on initiation of the DTR signal.
A simple jumper from the arduino board's reset pin to the 1284p reset pin should fix that situation. Try that and let us know how it works.
You may have to also remove the reset pull-up resistor on the 1284p chip as there is already a reset pull-up on the arduino board and having two in parallel may be too low a resistance for the auto-reset pulse to pull the signal low on initiation of the DTR signal.
Still, got the error, "avrdude: stk500_getsync(): not in sync: resp=0x00".
A simple jumper from the arduino board's reset pin to the 1284p reset pin should fix that situation. Try that and let us know how it works.
You may have to also remove the reset pull-up resistor on the 1284p chip as there is already a reset pull-up on the arduino board and having two in parallel may be too low a resistance for the auto-reset pulse to pull the signal low on initiation of the DTR signal.
Still, got the error, "avrdude: stk500_getsync(): not in sync: resp=0x00".
That's too bad. The error message just means that AVRDUDE and the bootloader aren't talking to each other. Are you sure you are selecting the proper comm port and board type (1284p) to use in the arduino IDE?
It's hard to debug hardware issues remotely. If I was there I would hook up the logic analyzer. Perhaps an LED and 1K resistor on each of Tx/Rx lines to confirm data is getting through?
Any ideas why I can change and upload the blink sketch as much as I want but as soon as I try to upload a larger file I get the error?
Edit: I am getting RX TX led activity for about 2 seconds than nothing. On smaller sketches this seems to be enough time to get it uploaded before it goes out of sync? I am so lost...
I get the same issue with teh 1284P using Mighty1284 Optiboot (Bobuino pinmap).
I can upload Blink but not larger sketches. I eventually gave up and just program via ISP. It's a bit of a pain for serial monitor as I have to keep switching my USB>TTL adapter to monitor, but I'm just going to order another cheap one to use with MTTTY for monitoring.
I have seen mention that trying a swap of the crystal resonator, or switching to a ceramic resonator can cure it, but I've not tried that as yet.
If anyone does know a link to a definitive fix then it would be useful to knoe.
tack:
I get the same issue with teh 1284P using Mighty1284 Optiboot (Bobuino pinmap).
I can upload Blink but not larger sketches. I eventually gave up and just program via ISP. It's a bit of a pain for serial monitor as I have to keep switching my USB>TTL adapter to monitor, but I'm just going to order another cheap one to use with MTTTY for monitoring.
I have seen mention that trying a swap of the crystal resonator, or switching to a ceramic resonator can cure it, but I've not tried that as yet.
If anyone does know a link to a definitive fix then it would be useful to knoe.
This really sounds like the 1284P DIP internal hardware bug effecting the serial input pin. The folks over at avrfreaks site had lots on it in the past. Seems the fix is to wire a low pass filter to the serial input pin which is a .1 ufd cap from the rec pin to ground and a series 10K resistor from the pin to whatever is supplying the serial data. Date code on the chip may or may not help identify a vulnerable chip. Another fix is to use a bootloader for the 1284P that was been compiled to use the second serial port on the 1284P that wasn't effected by with internal hardware bug. There was such a bootloader made available a while back by someone. Who remembers all those details.
And of course these days you can use a arduino board running the arduinoISP sketch and upload your sketch using the IDE file/upload with programmer option the IDE now offers.
I am getting an error message when trying to download the .hex and .txt file. Can you look into this please? I would love to see if those 2 files would fix my issue. Thanks