Go Down

Topic: Issue with Mighty 1284P Optiboot bootloader on STK500 (Read 11353 times) previous topic - next topic

wanderson

Jun 11, 2012, 04:52 pm Last Edit: Jun 11, 2012, 04:59 pm by wanderson Reason: 1
I have been playing with a 1284p chip and have a little trouble getting it to work with the core from https://github.com/maniacbug/mighty-1284p/zipball/master

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:

Code: [Select]

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.

ChrisS


spcomputing


wanderson


Either of you resolve this issue?


I haven't.  I use the original mighty ohm bootloader or straight wisp instead.

spcomputing

Yup, that and one other option is the UART1 version:
http://code.google.com/p/optiboot/downloads/detail?name=optiboot_atmega1284p-u1.hex&can=2&q=
Wouldn't be too bad with a second set of FTDI headers switching sketch programming and serial comms.

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

westfw

Quote
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 :-(

spcomputing

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

westfw

Hmm.  I found this:  http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=91002&start=0

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.  http://code.google.com/p/optiboot/issues/detail?id=30
(of course, when it doesn't work at all, there are fewer things to suspect of being wrong.)

spcomputing

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.

Wrong fuse bits for crystals and the 1284p?

wanderson


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.

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.

spcomputing


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 ;)

Steph

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.


spcomputing

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

Go Up