The FIGnition bootloader

[Cristian Arezzini]

Hello,
this is a "side question" while I'm trying to recover my bricked FIGnition.
I haven't really understood what is the relationship between a bootloader and the firmware: is the bootloader just a "protected area" of memory that can't be modified by the programs?
I was able to re-flash a bootloader into the chip using my EPROM programmer, and the plan was to use avrdude to transfer the firmware, but I had this problem: after flashing the bootloader, it "somewhat" works - i.e. the red led lights when powering up while holding SW1. But I can't get the computer to talk to it. Basically, I get the error "unable to enumerate USB device". And then of course avrdude fails.
Can this be due to the bootloader not working right? The hardware was OK before bricking the chip.
After uploading the bootloader to the chip, I verified it and it passes the test; but there were some options I really don't understand. The programmer asks me whether to program the LOCK bit and the Con.FUSE bit, and whether to program Code area, DATA area or both. I tried a few variations but it didn't help.
Is there another way to get the chip to talk back to the computer? By the way, I tried it on two different computers with the same result...

Cristian

[Julian Skidmore]

Hi Christian,

I'm about to head off to bed, but I'll reply about this in the morning :-) !

-cheers from Julz

BTW: It's fine of course to keep asking questions on the forum as that's what it's there for :-)

--
You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

                             
                  The DIY 8-bit computer from nichemachines™

[Julian Skidmore]

Hi Christian,

Sorry about the late reply.

The relationship between the bootloader and the application

*********************************************************************

The AVR's flash memory space goes from 0x0000 to 0x3FFF (on an AtMega168) or to 0x7FFF (on an AtMega328). By setting fuses on an AVR it's possible to configure the chip to support two programs: an application which starts at 0x0000 and a bootloader which can start 0.5Kb (in the case of the AtMega168), 1Kb, 2Kb , or 4Kb (in the case of an AtMega328) from the end of flash. This means that both the application/bootloader sections would begin with a set of interrupt vectors, the first one of which is the reset vector. In the case of FIGnition they're both set to 2Kb before the end of flash:

AtMega168: [0x0000:Application...][0x3800:Bootloader...0x3FFF]

AtMega328: [0x0000:Application...][0x7800:Bootloader...0x7FFF]

So, the question is, how does the AVR know which one to run? The answer is that other fuse settings tell it which one to run, but this can also be temporarily modified in software. So, normally FIGnition always resets to the bootloader, and the bootloader first checks to see if SW1 is already pressed - if it is, then FIGnition changes the vectors so that the application would be in control and then jumps to the start of the application.

Other Fuse Settings

***********************

But we also need to set other fuse settings so that e.g. the AVR knows it should expect the clock input to be taken from an external Crystal instead of an internal Resistor/Capacitor oscillator; and so that it knows that /RESET is still the reset pin and not PortC6 etc.

Setting up the Programmer

*******************************

So, there are two things you need to get right.

Firstly, you need to know which bootloader to store on a FIGnition. There's a different one for the AtMega168 and AtMega328 FIGnitions. On this page:

https://sites.google.com/site/libby8dev/fignition

FIGnitionBootloader.hex is the one for the AtMega168 and Bootloader328Rev1_0.hex is the one for the AtMega328.

Secondly, you need to know the correct fuse settings.

On the AtMega168 it's:  FuseLow=0xd7, FuseHigh= 0xd6, FuseExtended= 0xf8.

On the AtMega328 it's:  FuseLow=0xff, FuseHigh= 0xd2, FuseExtended=0xd7.

They basically mean the same thing, because the fuse bits are in a different order on the two chips (oddly enough).

I hope this helps!

-cheers from Julz

[Cristian Arezzini]

Julz... amazing! Very informative post, I had no idea it was so complex. Anyway, the fuse bytes did the trick - I just flashed the whole 1.0.1 firmware, with the correct fuse bytes, and it worked. Big thanks! It also saved me all the quite complex audio upgrade procedure: once set the fuse values, it was done in 10 seconds!
One thing I still don't understand: the 1.0.1 firmware uses up all the space between 0000 and 3FFF, including the space that you say should be for the bootloader (3800 to 3FFF). Does this mean that the firmware file also includes the bootloader?

One last question: is there a file that I can download, to flash the FLASH chip with my programmer, to have example programs and demos pre-loaded without having to type them in?

Thanks again for your help,
Cristian

[Julian Skidmore]

Hi Cristian,

> One thing I still don't understand: the 1.0.1 firmware uses up all the space between 0000 and 3FFF, including the space that 

> you say should be for the bootloader (3800 to 3FFF). Does this mean that the firmware file also includes the bootloader?

Yes, on an AtMega168 FIGnition that would be the case. The bootloader area on that device now contains the floating-point code and quite a bit of the audio loader code and a tiny, tiny, 128byte micro-bootloader. There's a gap at 0x3800 for the reset and interrupt vectors, and the reset vector points to the micro-bootloader.

So, this is how it was done on from a normal FIGnition installation (which would come with a USB bootloader at 0x3800 to 0x3FFF)

First we'd use avrdude to install a special application called the Migrator. The Migrator's only purpose is to load a new firmware image over audio. It can't load it directly into internal Flash, because then it'd overwrite itself; so it loads the image into external Flash. At the end, when the new firmware has been verified, it overwrites the old bootloader with the micro-bootloader (even though Atmel say that's impossible*) asks you to hold down SW1 and then jumps to the micro-bootloader.

The micro-bootloader expects a firmware image on external Flash in a fixed area; it downloads it from there updating the flash. 

Then you have firmware 1.0.x running on it :-)

With firmware 1.0.x on an AtMega168 you use the normal ear command to download new programs, including new firmware images.

-cheers from Julz

*If you haven't already seen it, the technique is called bootjacker: http://oneweekwonder.blogspot.co.uk/2014/07/bootjacker-amazing-avr-bootloader-hack.html

--

You received this message because you are subscribed to the Google Groups "FIGnition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fignition+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.