DualBoot on Atmega1284

[bhavinfirst]

Its a small but most essential part of our m2m project. We were looking for a solution for wireless programming solution independent of the transport layer and DualOptiboot does exactly that.

The problem is, Atmega328 just does not have enough RAM. For our application, we needed lots of RAM and atleast two uarts. Atmega1280 did not fit our bill (way too expensive). Our best bet was PIC32 series which has microchip released boot from SD bootloader. But again, SD cards add to BOM significantly with the added space and adapter requirements. Ofcourse we could modify the SD card bootloader to work with external flash, but we realized DualOptiboot does exactly what we want. With some discussion with Felix over mail, this is what we have come up with.

1. The chip used will be Atmega1284 (~4$ against 1.8$ for atmega328). Gives us lots of RAM and additional UART
2. Original Optiboot will be modified, taking cue from DualOptiboot. Aim is to get Atmega1284 compatible DualOptiboot.
3. Work on our application specific transport layer (to transfer image to external flash)

The project is yet to takeoff in full swing, so updates may be fewer initially.

Couple of key issues with current DualOptiboot
1. Application layer is responsible for transferring the file to the flash external flash memory and verify the image. In case there is a bug in the application software, the process may not work as intended and any future wireless updates will not be possible unless the device is reflashed.
2. To encounter issue 1, we intend to have a back up image of minimal required code for wireless programming. There should be a way for the chip to recognize there is a bug and then it should boot from the backup image. Not sure how the first part would work though.

One can very well argue, that application code should be tried and tested before deployment, but errors do happen, and when the device is at some remote location 1000's km from your lab, you cannot afford to brick it.

All suggestions are welcome and appreciated.

Regards

[bhavinfirst]

Felix,

Your Dual Optiboot seems to be branched out from Optiboot v4.4. This did not support Atmega1284.

Support for Atmega1284 has been added in Optiboot 5.0. The latest optiboot has changed the makefile structure. I don't think this will complicate things while writing Dual Optiport for Atmega1284, keeping your bootloader as reference. But I want to makesure, anything specific I should be careful about because of the changes in 5.0?

Regards

[Felix]

I didn't keep track of the Optiboot changes. I will take a look if I need to. Basically my DualOptiboot patch can be applied the same way.
The idea is to check for the flash image on the external EEPROM/FLASH at the right moment during boot. The bootloader cannot take the task of validating the image.
There's no real way that I can think of to do that or to switch to a backup image once the new image is flashed. The essential assumption is that the image written to the flash is valid, not corrupted, and integral. That's why I only store the information de-hexified and without the intel HEX format headers and checksum - so only the flash image itself without address information (the addresses are assumed incremental).
You should study flash images from HEX files, produced by gcc/winavr for atmega1284 and see if there are any oddities or gaps in the image addresses.

You will need to increase the flash image size (from 32K for 328P to 128K for 1284).
Also you need to modify the makefile to tell it where the start of the bootloader is. My changes increased Optiboot by about 500 bytes so essentially went from 512K to 1024K so address decreased by 512K. Also fuses will need to reflect this as well.

The ATMega1284P is about 3X the price of the 328P.

[tskon]

Hi,

is it possible to port this bootloader for the 2560 if I proceed with the above changes?

Thank you

[Felix]

I guess the only way to know is to try

[tskon]

Hi again,
I have been trying to port your bootloader and everything looks good except that it doesn't jump to application. I think it might be a problem with the bootloader address. I have defined as below
#elif defined(__AVR_ATmega2560__)
#define RAMSTART (0x200)
#define NRWWSTART (0x1FC00)

and:
 Mega has a minimum boot size of 1024 bytes, so enable extra functions
#mega: TARGET = atmega2560
mega: MCU_TARGET = atmega2560
mega: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' '-DBIGBOOT'
mega: AVR_FREQ = 16000000L
mega: LDSECTIONS  = -Wl,--section-start=.text=0x1fc00
mega: $(PROGRAM)_atmega2560.hex
mega: $(PROGRAM)_atmega2560.lst
It keeps looping and never resets.

 Could you help me with this?
Thank you!

[Felix]

Bootloaders start at the END of the address space. Say if the device is 32KB, and bootloader is 1K then the bootloader takes the space from 31-32K. When talking bootloaders the space they take is usually in words not bytes, 1 word = 2 bytes. You have to make sure the compiled bootloader does not exceed 1K, it should not. If you're forced to use 1K and it's under 1k compiled then just put it in the last 1K of memory as it should. You have to set the fuses right too ... I'm not familiar with 2560, I would suggest looking at other stock bootloaders and see what they do. I just took optiboot and injected my stuff in it, ended up going from 512b to just under 1K, so I had to shift the address space from 31.5K to 31K so it would fit, everything else stayed the same.