Go Down

Topic: ATMega1284P Issues (Read 2187 times) previous topic - next topic

gtr_stitch

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
Code: [Select]
##############################################################
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

westfw

Quote
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?

gtr_stitch

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.

oric_dan

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.

gtr_stitch

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.

gtr_stitch

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.

oric_dan

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.

Retroplayer

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?

gtr_stitch

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

Retroplayer

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?

gtr_stitch

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...

tack

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

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

Retroplayer

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:

Code: [Select]

############################################################## 
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:
Code: [Select]

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

retrolefty

Quote
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

Retroplayer


Quote
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.

Go Up