ATmega1284P: End to End using 1.0 IDE

you typically have to give the -F option to avrdude to force it to burn anyway, since otherwise it'll error with a signature mismatch

Or modify the signature in avrdude.conf.

I haven't a clue as to the difference between the 1284 and the 1284P.

I'm spreading a rumor that the non-P versions are chips that failed power consumption testing late in manufacturing. :slight_smile:
Usually when there are two versions of a chip like this, the manufacturer is pretty careful to distinguish the differences. And in this case the non-P versions showed up AFTER the picopower versions had been released (328 vs 328P too.)
Even if this theory were to be true, it wouldn't necessarily be a bad thing...

Found a difference between 1284 & 1284P!

Section 12.2 Interrupt Vectors in ATmega164A/164PA/324A/324PA/644A/644PA/1284/1284P
4 extra interrupts:
Vector: 32, Program Address: 003E, Source: TIMER3_CAPT, Interrupt Definition: Timer/Counter3 Capture Event
33, 0040, TIMER3_COMPA, Timer/Counter3 Compare Match A
34, 0042, TIMER3_COMPB, Timer/Counter3 Compare Match B
35, 0044, TIMER3_OVF, Timer/Counter3 Overflow

westfw:
I have burned bootloader from the IDE, and then successfully uploaded sketches, using one of crossroad's Bobuino boards, Arduino Uno as ISP (for burn), and genuine FTDI cable for upload.

I am having zero luck with this. I just got a batch of 1284Ps in from Digikey today. Built on a breadboard, with a resonator (3-pin type) and FTDI cable for serial TX/RX. 0.1uF between DTR and reset, reset pulled-up by 22K resistor. Used an Uno to upload the Optiboot from Maniacbug's distro package, and version 4.5 from the repo.

I get this when uploading a sketch:

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

Swapping TX/RX makes no difference, but I'm pretty sure I got that part right to begin with. (I use this setup A LOT for 8As and 328/328Ps.)

Uploading a sketch via programmer works fine, so I know the ATmega life support system is doing OK. Using a modified Blink to blink pin D14, which is currently attached to the backlight of an LCD, I get on, 1s, off, 1s.. as expected.

I admit, I've not paid much attention up til now, as I just found a project that needed the I/O and RAM to justify a 1284P, so maybe I missed something obvious, but my catch-up searches haven't revealed anything useful.

I noticed that when the Blink sketch was uploaded (via ISP), there was no noticeable delay between reset and blink. I'm used to there being a little window where the serial upload might interject before running the payload code. Is that normal for upload via ISP? Does that overwrite the bootloader entirely? Or is Optiboot just not waiting?

Sketch upload via ICSP means no bootloader, sketch starts immediately. No bootloader in place after that.

Which would make serial upload dead in the water.

After you get a bootloader re-installed, you might try checking the fuses. Maybe something funny is set there.

I have a similar test setup:

What I've been doing is programming fuses, programming lockbits, then programming memory.

Interface settings: 125 KHz for first time bootloading (Atmel AVR ISP MKii allows you to select the programming speed)

Memories:
C:\Arduino-1.0\hardware\mighty-1284p\bootloaders\optiboot\optiboot_atmega1284p.hex
Erase before programming- checked
Verify after programmimg - checked

Fuses:
BODLEVEL 2.7V (or as you select)
SPIEN - check
BOOTSZ - 512W_FE00
BOOTRST - check
SUT_CKSEL - EXTX0SC_8MHZ_xx_16KCK_65MS

Fuse Register
Extended - 0xFD
High - 0xDE
Low - 0xFF

Lock Bits: all show No Lock, Lock Bit Register to show 0xFF

Ah, well now for some reason the serial uploads are starting, but losing sync shortly thereafter. I guess that's progress. :slight_smile:

Really odd though. When I upload a sketch via ISP that uses the serial monitor, everything looks fine. So I think I can rule out wiring and clocking issues.

Yes, just software settings at this point.
I was having the same issues. Could show the hardware all worked, couldn't do a serial download.
Using the AVR ISP MKii to get the fuses set correctly helped. Then using maniacbug's 1284 setup from there for Bobuino for the pinout I am using.

Just found this thread, read through the last 10 pages and I do not feel alone anymore :~ . I have been trying to get a 1284P to work on a Sanguinololu ( Sanguinololu - RepRap ) board and it has been a struggle. Everything works with a 644P so the hardware is fine.

I have had some success on version 0023 but that does not compile the code that I need in the chip ( GitHub - ErikZalm/Marlin: Reprap FW with look ahead. SDcard and LCD support. It works on Gen6, Ultimaker, RAMPS and Sanguinololu ) and the 1.0 IDE does compile the code but I cannot get the IDE to connect to the board (it does work with the Duemilenove and Uno). I am using maniacbug 1284p firmware ( GitHub - maniacbug/mighty-1284p: Mighty 1284P Platform for Arduino ) that I can get into the chip with 0023 and a Duemilenove acting as ISP. Blink works (in many different pins) and the timing is correct using 0023.

1.0 will not talk to the Sanguinololu. I have tried changing the fuse settings as seen here (Steves Fix It Shop: Sanguinololu 1.3a - Part 3:Not Out of The Woods Yet ) with some interesting responses on the verbose mode on the IDE but no talk. The Sanguinololu uses a ceramic resonator for 16MHz and I have tried to decipher the fuse calculator ( AVR® Fuse Calculator – The Engbedded Blog and a little easier to understand here ATmega164A(P)/324A(P)/644(A)(P)/1284(P) Fuse Calculator ) to no avail.

The people on this thread seem to be quite knowledgeable about the task at hand as the title says, so if anyone can provide some hints that would be greatly appreciated.

bluemetal:
Just found this thread, read through the last 10 pages and I do not feel alone anymore :~ . I have been trying to get a 1284P to work on a Sanguinololu ( Sanguinololu - RepRap ) board and it has been a struggle. Everything works with a 644P so the hardware is fine.

I have had some success on version 0023 but that does not compile the code that I need in the chip ( GitHub - ErikZalm/Marlin: Reprap FW with look ahead. SDcard and LCD support. It works on Gen6, Ultimaker, RAMPS and Sanguinololu ) and the 1.0 IDE does compile the code but I cannot get the IDE to connect to the board (it does work with the Duemilenove and Uno). I am using maniacbug 1284p firmware ( GitHub - maniacbug/mighty-1284p: Mighty 1284P Platform for Arduino ) that I can get into the chip with 0023 and a Duemilenove acting as ISP. Blink works (in many different pins) and the timing is correct using 0023.

1.0 will not talk to the Sanguinololu. I have tried changing the fuse settings as seen here (Steves Fix It Shop: Sanguinololu 1.3a - Part 3:Not Out of The Woods Yet ) with some interesting responses on the verbose mode on the IDE but no talk. The Sanguinololu uses a ceramic resonator for 16MHz and I have tried to decipher the fuse calculator ( AVR® Fuse Calculator – The Engbedded Blog and a little easier to understand here ATmega164A(P)/324A(P)/644(A)(P)/1284(P) Fuse Calculator ) to no avail.

The people on this thread seem to be quite knowledgeable about the task at hand as the title says, so if anyone can provide some hints that would be greatly appreciated.

Just for the heck of it ... What fuses are you trying right now? (I was just knee-deep in the Atmel datasheet for the chip so it's fresh in my head...)

I tried D6 DC FF as listed on the website above, besides the usual suspects FF 99 FF (Sanguino 23R3), FF DE FD (Mighty1284P) plus a few other ones just to see if it generated different responses (it did).

It worked for me with the fuses FF 98 FD.

I went ahead and removed the resonator from the Sanguinololu 1.3a board and replaced with a mini 16MHz crystal (so it would fit inside the IC socket) and 2 x 20pf capacitors on the bottom side of the board. Set the fuses to FF DE FD and used Maniacbug bootloader ( GitHub - maniacbug/mighty-1284p: Mighty 1284P Platform for Arduino ) with 16 MHz 1284P with optiboot in Arduino 1.0 and everything worked perfectly. Managed to upload the 82K large Marlin 1.0 firmware (for 3d printing) and it performed correctly communicating properly with Pronterface (the interface with the Sanguinololu board).

I will try to retrace all the steps and check all other items that have lined up to success, but the same software setup without the crystal did not work the night before.

Could be the resonator is not quite stable at the higher serial download speeds?
I only use crystals/caps, unless a customer asks for a resonator to mimic a known design.

It could be, but I did try to use the lowest possible speeds (all the way down to 9600) for bootloading and uploading (via the makefile and boards.txt) without success before the crystal. I am still putting my money on wrong fuses as the main culprit and transmission speeds as an evil sidekick. ]:smiley:

I wish there was an easy way to decipher those fuse options for the 1284P.

I've head resonators fail when the fuses were set for a crystal, on ATmega8, where the datasheet says:

For resonators, the maximum frequency is 8 MHz with CKOPT unprogrammed and 16 MHz with CKOPT programmed.

(and CKOPT is the difference between "low power" and "full swing" oscillators. Clock options are different on m1284 and m328, but it might be worth experimenting with.

Fail as in "break" fail, or just not work?

I have confirmed that the resonator (and corresponding fuse setting) is the culprit.

I have 2 identical Sanguinololu 1.3a boards. One with the 16MHz crystal and corresponding caps and one with the resonator. The crystal one works with the 1284P at 16 MHz and the one with the resonator does not (no uploading). The same IC and the same computer settings.

I guess the recommendation is to use a crystal when running a 1284P at 16MHz so you do not need to change fuses.

(fail as in "just not work.") (A fix for this was applied to the optiboot make files. Google Code Archive - Long-term storage for Google Code Project Hosting. )

bluemetal:
I guess the recommendation is to use a crystal when running a 1284P at 16MHz so you do not need to change fuses.

Good work discovering the issue! I only have used crystals with my 1284Ps so I never ran into this issue. Lucky!