I have the chip on a STK500 and used a standard c program to verify that its fuse are correct and that it works. I then burned the Tools > Board > Mighty 1284p 16MHz using Optiboot bootloader and was unable to get the IDE to upload to the chip. I would get the following error:
Binary sketch size: 3,410 bytes (of a 130,048 byte maximum)
/usr/share/arduino/hardware/tools/avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega1284p -carduino -P/dev/ttyUSB2 -b115200 -D -Uflash:w:/tmp/build8867354308208977374.tmp/test_entropy.cpp.hex:i
avrdude: Version 5.11.1, compiled on Oct 30 2011 at 10:37:28
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/usr/share/arduino/hardware/tools/avrdude.conf"
User configuration file is "/home/wandrson/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB2
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude done. Thank you.
However if I choose the other bootloader (Tools > Board > Original Mighty 1284p 16MHz) The process works fine. Not sure what is causing the problem with the Optiboot based bootloader, and if I can help debug, please provide guidance!
Oh, and even though the chip is running on a STK500, I am using a AVR ISP MK II to do the actual programming of the bootloader.
I was under the impression it was an AVRISP MkII was immune to the problem, apparently not. Cyclegadget says he has no problems with Nick Gammon's Atmega Bootloader Programmer, but same problem occurs.
I wonder if we could talk Westfw out of the source for optiboot_atmega1284p-u1 and switch the UART1 back to UART0...
if we could talk Westfw out of the source for optiboot_atmega1284p-u1
That's just it; the sources that are in the google code repository ARE the ones used to build the -u1 hex file, only with '-DUART=1' added to the atmega1284 build in the makefile. Doing that produced a Hex file identical to the u1 download, and building a normal (uart=0) hex file from those sources results in a hex file that is identical to the 4.5 download (except for the version number location, which really shouldn't matter. (hmm. If the BOOTRST (bit 0 of the "high" fuse) fuse was set incorrectly (should be a zero), the extra bytes in low memory might cause odd behavior. But ... no, it shouldn't matter even then; even executed as an instruction, the version number doesn't do anything relevant.))
Disassembling the .hex file that people are having trouble with show code that looks like it should be OK (absolving possible compiler include file errors.)
I can't see why it's not working, or why uart1 would work
@westfw: I switched the High Fuse between DE and DF (Toggle BOOTRST bit) and no change. Uploads Blink fine, but no large sketches.
I am just confused on why a portion of 1284p users have no trouble and some of us do. I thought it might be something special with the AVRISP, but wanderson is also having issues. I will check out your Optiloader tomorrow.
Try changing the Low fuse (LFUSE) from 0xFF to 0xF7, which should change the crystal oscillator from "low power" to "full swing" (at the expense of slightly higher power consumption.)
This sort of thing would explain the randomness of the failures; they'd depend on exactly which crystal you had used, and which caps, and so on. I actually had a similar problem with ATmega8 chips using ceramic resonators - with the original fuses in the optiboot Makefile, my mega8 board wouldn't run at all. Google Code Archive - Long-term storage for Google Code Project Hosting.
(of course, when it doesn't work at all, there are fewer things to suspect of being wrong.)
Well, bad news is no go on the the low fuse at 0xF7 and 16MHz crystal and caps. Just a flat out no sync error (as opposed to a paged_write).
Good news is that possibly the reason so many people are having little trouble is that they are running a ceramic resonator instead. The resonator works perfectly with lfuse 0xF7 (not 0xFF). I almost always use a crystal and caps to avoid this issue, but hey
I tried different crystals (+/-20ppm) before with no change. I use the same crystals all day long in other Atmega8 projects with no trouble.
spcomputing:
Good news is that possibly the reason so many people are having little trouble is that they are running a ceramic resonator instead. The resonator works perfectly with lfuse 0xF7 (not 0xFF). I almost always use a crystal and caps to avoid this issue, but hey
Well, not me at least. I either use the internal clock, an external crystal, or an external crystal oscillator. The circuit I reported with the error was an external crystal.
spcomputing:
Good news is that possibly the reason so many people are having little trouble is that they are running a ceramic resonator instead. The resonator works perfectly with lfuse 0xF7 (not 0xFF). I almost always use a crystal and caps to avoid this issue, but hey
Well, not me at least. I either use the internal clock, an external crystal, or an external crystal oscillator. The circuit I reported with the error was an external crystal.
Exactly, and there were 3-4 forums/blogs that had the same issue and when they switched to the crappy resonator and adjusted the lfuse, poof, all fixed. The question still remains of what settings will get the 1284p onto an external crystal...Sanduino operates on an external crystal.
Rats. My (working) board does have a resonator...
Although if the same optiboot works with a res but not a crystal, I might be inclined to absolve the code.
westfw:
Rats. My (working) board does have a resonator...
Although if the same optiboot works with a res but not a crystal, I might be inclined to absolve the code.
I am inclined to absolve the code as well, but you did open that "Pandora's Box" with the UART1 variant. I ran through a lot of fuse setups of the other Atmel Megas, and the 1284p is truly weird. I am a bootloader user, not an expert, but all the other Atmegas use SUT0 and SUT1 for the Arduino/Optiboot setup, but not the 1284p. Curious...
Have you Opti-booted a Sanguino (you mentioned familiarity with the system)?
I thank you for relieving more than one my frustration with the resonator insight on the 1284. If you are inclined to work further on the external crystal, and need a runner for tests and such, let me know. I would appreciate the shortest traversing of 512 bit combinations as possible
Sorry if this is off topic - I've been following this and similar threads as I'm using the '1284P in a custom project.
I'm wondering what is the advantage of using Optiboot on the 1284? I understand that fitting the bootloader in 512 bytes is a big improvement on a '168 or a '328 because the overall flash size is much smaller, but the '1284 has loads of flash. And the smallest bootloader you can specify with fuses is 1024 bytes.
Are there other advantages to Optiboot, beyond it having a small footprint?
FWIW I'm using a 'standard' Arduino bootloader that fits inside 2048 bytes, and it is working fine for me. My board is using a ceramic resonator at 8MHz and I've set the bootloader for 57600 baud.
I'm wondering what is the advantage of using Optiboot on the 1284? I understand that fitting the bootloader in 512 bytes is a big improvement on a '168 or a '328 because the overall flash size is much smaller, but the '1284 has loads of flash. And the smallest bootloader you can specify with fuses is 1024 bytes.
I suppose; for me, it is simply the principle of the matter. It should work, it works on all kinds of others of the Atmega family, and finally the "Works fine for me..." meme.
Technically speaking/thinking, there is very little advantage for Optiboot other than communication speeds. I have noticed that serial communications are cleaner with optiboot and a resonator than the original 1284 bootloader and a crystal. This makes my head numb.
I don't know if there was ever an admission or fix out of Atmel.
Perhaps this is why "modern" processors don't appear in DIP form
Do we know that the TQFP is less susceptible than the DIP? That might surprise me a bit given that the topology of pins in question is the same, at least externally. I'm not clear whether the issue is with the package, the die, some combination of the two, etc.
Have been reading up on this here, avrfreaks, and a couple other places. Interesting.
Actually the issue has seemed to have been solved, at least for the population of people around here working on getting a 1284P going. Changing the fuse byte to use the full swing oscillator option from the prior low power oscillator option, seems to have cured the problem symptom in it's track, no need for external filtering components, etc.
The problem was not being seen by all users of 1284P chips/boards, but to the best of my knowledge and memory no one has reported that changing to full swing oscillator fuse bit has failed to fix their problem.
retrolefty:
Actually the issue has seemed to have been solved, at least for the population of people around here working on getting a 1284P going. Changing the fuse byte to use the full swing oscillator option from the prior low power oscillator option, seems to have cured the problem symptom in it's track, no need for external filtering components, etc.
The problem was not being seen by all users of 1284P chips/boards, but to the best of my knowledge and memory no one has reported that changing to full swing oscillator fuse bit has failed to fix their problem.
Lefty
Ah OK, thanks. Must have missed that tree while trying to see the forest.
