ATMega1284P Issues

Using Arduino Microcontrollers
1

So, I've gotten my hands on the beefy ATMega1284P, and after finally burning the Mighty Bootloader, I can't seem to upload sketches at all. I always get that out of sync error. I've changed the fuses as stated by many different posts. Changed the conf file and the boards.txt file as suggested, but nothing seems to work. I'm fairly certain the bootloader was burned properly, as the indicator led blinks when I press the reset button. After some reading, though, I saw that the 1284 doesn't work with stk500. in the boards.txt file, the upload protocol states arduino, but the IDE tells me stk500_getsync(): not in sync: resp=0x00. I'm kinda lost now. All I have is the Arduino UNO board acting as an ISP. I don't really have the privilege of owning any other ISP. Any pointers? Tips? I've gone through a lot of tutorials and forum posts, but I can't seem to get this thing running.

~Stitch

##############################################################
mighty_opt.name=Mighty 1284p 16MHz using Optiboot
mighty_opt.upload.protocol=arduino
mighty_opt.upload.maximum_size=130048
mighty_opt.upload.speed=115200
mighty_opt.bootloader.low_fuses=0xf7
mighty_opt.bootloader.high_fuses=0xde
mighty_opt.bootloader.extended_fuses=0xfd
mighty_opt.bootloader.path=optiboot
mighty_opt.bootloader.file=optiboot_atmega1284p_16.hex
mighty_opt.bootloader.unlock_bits=0x3F
mighty_opt.bootloader.lock_bits=0x0F
mighty_opt.build.mcu=atmega1284p
mighty_opt.build.f_cpu=16000000L#
mighty_opt.build.core=arduino:arduino
mighty_opt.build.core=standard
mighty_opt.build.variant=standard
2

I saw that the 1284 doesn't work with stk500. in the boards.txt file, the upload protocol states arduino, but the IDE tells me stk500_getsync()

The "arduino" protocol is a minor variant of the stk500v1 protocol, so all the error messages will still refer to STK500.

So which 1284 board do you have, and/or what device do you have doing the USB/Serial conversion?

3

Well I guess that makes sense...
But I've got two of the 1284P chips (from what ive read, seems to be some issues with them) and I'm using my Uno board as the ISP.

4

I think the issues have been resolved with the 1284P chips. Use the full
swing oscillator fuse setting, or if wanting to go commando mode, put
an RC filter on the RX0 pin [5-10K, 100 pF], and "don't blink".

If you don't care to do either, it helps to have a proper pcb layout in
the first place.

5

I'll give the RC filter a go. I did change the fuse value from 0xFF to 0xF7. I'm doing this all on a breadboard. The bootloader seems to have burned fine, it's just uploading a sketch that is proving problematic.

6

I don't know if this is any information that'll help me, but I'm not really using the Arduino as ISP, rather, using the 16u2. I don't know if it makes a difference. I read here (http://nathan.chantrell.net/20120811/using-the-atmega1284p-with-the-arduino-ide-wiz820io/) and noticed he was using a .1uF cap in conjunction with a 10K resistor on the dtr line (dtr is the same as Reset on the arduino board, correct?). If so, I think i'll implement his setup alongside the RC filter, and see if that gives me any results.

7

The .1uF cap is always used between DTR and Reset pin, at least when FTDI
cables are being used, and the 10K pullup is necessary to hold the Reset pin high.
That's just normal hookup.

8

This might be a silly question, but I don't see anything in your posts addressing it, but what are you using for a clock on the 1284P?

9

I've got a 16Mhz ceramic resonator as the crystal. Would that have something to do with it?

10

Probably not. That should be fine. Are your fuses set to use it?

Also, another one of those "Is it plugged in" questions:

Did you program a bootloader in the chips already?

11

I believe so...
mighty_opt.bootloader.low_fuses=0xf7
mighty_opt.bootloader.high_fuses=0xde
mighty_opt.bootloader.extended_fuses=0xfd

I have OptiBoot burned onto both...although...the first one, upon cycling the power, the led blinks a little erratically. the second one is the usual three blinks...
And, dumb moment...I didn't read the resonator well. It says 16.93 (not 16). I used that to while burning the first bootloader, but, I created the monster you see below for the second, and tapped into the onboard 16Mhz crystal on the Uno, while using an ATMega328 on a breadboard at 8Mhz to burn the bootloader on the second chip. However, I am still getting those not in sync error messages...

WP_000935.jpg
WP_000935.jpg717×538 105 KB

12

1st issue may well be out of sync due to wrong crystal.

Second issue; how exactly have you 'tapped into' the Uno onboard crystal.

13

The resonator being at 16.9Mhz is probably not a big deal. It may screw up your timing a bit, but it shouldn't be causing your issues.

The res=00 part says that avrdude is not even seeing your bootloader. Generally, that is:

Lack of power, lack of clock, no bootloader, wrong protocol, or the bootloader is not ready for an upload.

We obviously have power since you say you can see the lights blinking.
As for the clock - for stability, I would go back to using the resonator. The Uno is also using a resonator, anyway.
Your blinking lights indicate that you have a bootloader
And if you don't already have a sketch on there, it should be always running in the bootloader, so it should be ready for an upload. Though, you will need to keep in mind the 'reset' part needed to get into the bootloader for later.

So that leaves the most likely culprit as the protocol...

The proper protocol IS stk500. It is the original arduino bootloader that cannot address the extra memory. This is the boards.txt for an atmega184P from the optiboot page:

 ##############################################################  
atmega1284o.name=[Optiboot] ATmega1284p 
atmega1284o.upload.protocol=stk500 
atmega1284o.upload.maximum_size=130048 
atmega1284o.upload.speed=115200 
atmega1284o.bootloader.low_fuses=0xC7 
atmega1284o.bootloader.high_fuses=0xde 
atmega1284o.bootloader.extended_fuses=0x05 
atmega1284o.bootloader.path=optiboot 
atmega1284o.bootloader.file=optiboot_atmega1284p.hex 
atmega1284o.bootloader.unlock_bits=0x3F 
atmega1284o.bootloader.lock_bits=0x0F 
atmega1284o.build.mcu=atmega1284p 
atmega1284o.build.f_cpu=16000000L 
atmega1284o.build.core=arduino:arduino 
atmega1284o.build.variant=arduino:standard

I did change this one line:

atmega1284o.bootloader.low_fuses=0xC7

It originally read 0xF7 but that is more suited for a crystal. C7 is intended for a ceramic resonator. That probably isn't your problem here (since you are getting blinking lights), but for stability-sake that's the fuses I would personally go with. Note that just changing it in your boards.txt file isn't going to change anything unless you reburned the bootloader using ISP.

If the crystal vs. resonator is somehow your issue, it would most likely be an issue with the upload speed. In both the boards.txt that you posted and this one, we are trying to upload at the fastest possible rate of 115200. You might have to dial that down. Try changing it to 57600 and finally 19200 if that doesn't work.

But, first, try changing your upload.protocol to stk500

14

The resonator being at 16.9Mhz is probably not a big deal. It may screw up your timing a bit, but it shouldn't be causing your issues.

I would not make that assumption. I would first suggest changing to a 16Mhz resonator and retest.

Lefty

15

retrolefty:

The resonator being at 16.9Mhz is probably not a big deal. It may screw up your timing a bit, but it shouldn't be causing your issues.

I would not make that assumption. I would first suggest changing to a 16Mhz resonator and retest.

Lefty

He already tried that (tapping off the Uno board)...

it didn't work.

I think my assumption is perfectly safe.

16

Actually, using a 16.934Mhz oscillator makes for a more accurate buadrate division which means less errors:

Freq (MHz) Buadrate Notes
16.9344 115200 Used in CD-DA systems and CD-ROM drives; allows integer division to 44.1 kHz (384×44.1 kHz), 22.05 kHz, and 11.025 kHz. Also allows integer division to common UART baud rates up to 115200. Frequencies also used are 11.2896 MHz, 22.5972 MHz, 33.8688 MHz and 45.1584 MHz.

(error rate of 3.7% at 16MHz vs. 2.0% at 16.934Mhz so still not 'perfect' but actually better than 16Mhz exactly.)

17

Tak - Refer to image. I simply used jumpers to connect the onboard 16Mhz resonator.

And a lot of great info. Ill surely look into that and post back. Much appreciated!

18

using a 16.934Mhz oscillator makes for a more accurate buadrate

Not if the bootloader was compiled assuming a 16MHz clock. That will yield nearly 8% error, if I calculated right.

19

gtr_stitch:
Tak - Refer to image. I simply used jumpers to connect the onboard 16Mhz resonator.

And a lot of great info. Ill surely look into that and post back. Much appreciated!

I can't follow the connections from the photo, there are just too many long looping jumpers everywhere.

You've got an Uno with no MCU and then two breadboards, one with a 328 and another with 1284.

Are you trying to share the Uno 16mhz crystal with both of these? If so then you can't just pick up both sides on the crystal to both XTAL pins on each chip. On one you drive the crystal normally and on the other just link the crystal output to XTAL in of 2nd chip I believe.

Also bear in mind that the XTAL pins are the opposite way round on 1284 vs 328. On the 328 it's the low impedance pin adjacent signal pin. On the 1284 it's the high impedance XTAL pin adjacent The RX0 signal pin. This is one reason we had issues with serial uploads on 1284 without adequate ground rings or full swing oscillator; the high z XTAL pin on 1284 seemed to susceptible to capacitively induced interference from the adjacent RX0 pin.

20

Still out of sync. I guess I'll just scrap the 1284s. I don't have the resources to purchase an external programmer or whatever will work with these uC's. Oh well.