1280/2560 bootloader from SD

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If someone is interested, I developed for a customer a bootloader that reads a file from an SD card and reflashes the application.
The code is based on FAT16 and SDCard libraries for Arduino, even if our hardware is no (longer) Arduino.

It works with 1280 and 2560. The bootloader area should be configured at the maximum size.

It wasn't difficult to develop, and I suppose everyone can do the same in short time - but this is already working and tested, so it can be a starting point.

Let me know...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So post it as a project and announce it in the Academy Forum.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
So post it as a project and announce it in the Academy Forum.
Done!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having some issues with compiling the boot loader.
Please help.
I get the following errors:

Error 8 ld returned 1 exit status collect2.exe 0 0 sdbootloader
Error 1 undefined reference to `__udivmodsi4' /Fat16.cpp 254 1 sdbootloader
Error 4 undefined reference to `__udivmodsi4' /Fat16.cpp 643 1 sdbootloader
Error 5 undefined reference to `__udivmodsi4' /Fat16.cpp 649 1 sdbootloader
Error 2 undefined reference to `__umulhisi3' /Fat16.h 372 1 sdbootloader
Error 6 undefined reference to `memcmp' /Fat16.cpp 344 1 sdbootloader
Error 7 undefined reference to `memcmp' /Fat16.cpp 962 1 sdbootloader
Error 3 undefined reference to `memcpy' /Fat16.cpp 524 1 sdbootloader

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's something wrong with your linker. It should be configured so it automatically links with libc.a yet that does not appear to be happening. Is this a compiler you built yourself?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah ok. I am using AVR Studio 6. Any suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you post the AS6 project files zipped up so others can try building this? There's no doubt that the compiler/linker in AS6 is built right so if it makes a fundamental error like not being able to find/link with one of the system libs I strongly suspect something is being passed on the command line to tell it to behave that way.

In fact in AS6, with the Project properties AVR/GNU Linker-General has a tick box marked "do not use default libraries (-nodefaultlibs)". If for some strange reason you had chosen to tick that option it would explain exactly what you are seeing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah thank you! That was it. For some reason -nostdlib was checked

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the code exactly as is from the project running on a mega@3.3V but I cannot seem to get it to work. It will delete the file off of the SD card but not actually run the code that I have given it. I have tried a very simple blink file. That doesn't work.
https://dl.dropboxusercontent.co...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's my take on the same idea:

http://spaces.atmel.com/gf/proje...

Admittedly I only built/tested with mega16/32 so it may/may not work with mega128. I would guess you'd be OK up to 64K of code but as I don't (yet!) have handling for >64K code flash it likely will not write a "big" program to a mega128. But an LED flasher should work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to run it on a 2560 sorry if I failed to mention this. I'm also sorry if I sound like I don't know what I am doing. I am very new to AVR and C programming. (all my experience is with arduino)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Once you get passed 64K of code then whether it's mega128 or mega256(1/0) matters little. However it's usually a pretty long time before anyone manages to break 64K (unless a lot of graphics, video or audio data are involved.

I'm simply saying it may be worth trying my code as an alternative just to prove the electronics (wiring of SD/MMC etc). If two different software fail it's likely a hardware issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mrjonny2 wrote:
I am having some issues with compiling the boot loader.

Hello, sorry for the late answer.

I will try this evening to compile the code.

If I remember correctly, the project was for AS6.0, but I didn't attempt to compile it with the latest 6.1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: yes, there was a -nostdlib in the linker section. It must be unchecked to have the project compiled.
Tomorrow I should have a board at my disposal, so I can test the code and see what happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would it be possible to use FAT32 instead?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Here's my take on the same idea: http://spaces.atmel.com/gf/proje... Admittedly I only built/tested with mega16/32 so it may/may not work with mega128. I would guess you'd be OK up to 64K of code but as I don't (yet!) have handling for >64K code flash it likely will not write a "big" program to a mega128. But an LED flasher should work.
My one has build options for FAT16 or FAT32. Of course the added complexity of FAT32 makes it a bit larger than the FAT16 only variant. As I say I have not worked on >64K flash so if that is what you have in mind it could require a little tweaking.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WOW!!! half hour response on a 4 year old thread. I wasn't really hopeful, but now I am truly impressed.

I feel like I don't belong here, because admittedly I have never left the comfort of the Arduino IDE. I am more of a HW kind of a person.

My project involves ATmega2560 based controller, with web server. I already have a FAT32 SD card in the system for the purpose of web file storage, and future data logging.

As a part of my server I am able to upload files to the SD card, and in that manner update the web content, but now I am considering firmware update by uploading firmware.bin.

Since I have developed the web server, I can intercept the file name, and react to it as I please, so the plan is as follows:

 

1- upload the firmware.bin file from the remote web browser

2- server running on mega recognizes file name, and 

  2a- checks the integrity of the file (maybe decrypts)

  2b- saves ready to use fw.bin (checked and / or decrypted)

  2c- triggers the reset (I didn't check is it possible to do this by sw, but if not I can dedicate the suicide pin to do this in HW)

3- bootloader checks for fw.bin file, and if available copies it into the flash. It would be nice if it still supported serial bootloading.

4- main program in the controller after reset checks for fw.bin, and erases it in order to prevent redundant bootloading after each subsequent reset.

 

I believe that this solution would be of great interest to the Arduino community since it would enable practical firmware update on the remote boards without end user involvement.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dariofil wrote:
As a part of my server I am able to upload files to the SD card, and in that manner update the web content, but now I am considering firmware update by uploading firmware.bin.

Since I have developed the web server, I can intercept the file name, and react to it as I please, so the plan is as follows: ...

Most of those steps are in SerialBootloader (app note AVR2054, document PDF and zip for source code)

Some of its AVR are the mega256 RF AVR; could port it to mega2560 replacing the wireless network interface and stack with the network interface and stack used by the web server.

http://www.atmel.com/products/microcontrollers/avr/avr_xmega.aspx?tab=documents

Document Type pull-down menu, Application Notes

...

 

Atmel AVR2054: SerialBootloader User Guide
(file size: 420KB, 23 pages, revision D, updated: 03/2015)

(Software: file size: 30.2MB, version 3.2.0, updated: 03/2015)

 

The AVR2054 Serial Bootloader is a standalone, serial boot loader utility for use with Atmel wireless software stacks. It supports MCU programming via UART/SPI/TWI interfaces and also includes features required for Over-the-Air firmware Upgrade (OTAU). Atmel PC-based application for serial and over-the-air programming is also included in the package.

 

Microchip Technology Inc

Microchip

AN_8390

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591948

AVR2054: SerialBootloader User Guide

...

 

Edits : menu, typo

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Apr 26, 2017 - 06:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mr. gchapman, I appreciate the info, I will check it out. Some "real work" just rolled in, so it may take me a while to get back to real real work.

 

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dariofil wrote:
1- upload the firmware.bin file from the remote web browser 2- server running on mega recognizes file name, and 2a- checks the integrity of the file (maybe decrypts) 2b- saves ready to use fw.bin (checked and / or decrypted) 2c- triggers the reset (I didn't check is it possible to do this by sw, but if not I can dedicate the suicide pin to do this in HW) 3- bootloader checks for fw.bin file, and if available copies it into the flash. It would be nice if it still supported serial bootloading. 4- main program in the controller after reset checks for fw.bin, and erases it in order to prevent redundant bootloading after each subsequent reset.

You need to take a step back and think about this deeply.

 

A bootloader should be a completely standalone piece of software with no reliance on the software it may replace. Consider a couple of scenarios:

 

1) the bootloading operation is taking place then the power unexpectedly dies. The device is now left with "half an application program" burned into it.

 

2) new code is delivered. A bug in the code that only affects 10% of the population of devices now renders them unable to communicate with the server that may subsequently deliver repaired/updated code images

 

Now in your proposed scheme issue (1) is not such a problem because before the program replacement process starts you will already have received a complete fw.bin so if the burning process is interrupted, at next reset the bootloader can just try again. The code has already arrived so you should be OK.

 

But (2) could be a bigger problem. The replacement of the code is done independently by the bootloader so that part is OK but the arrival and triggering of the bootloader process is reliant on the application code operating correctly so if it is "damaged" in some way this process may never be able to receive/trigger again.

 

This is why most bootloaders are written as a one time, 100% bug free piece of code that never changes and that has NO reliance on the code that it sometimes replaces. To do this you would need to put all the stuff necessary to receive a copy of fw.bin, write it to SD and then later SPM it to the app section (receiving first is still a good idea when you have the local storage for it) into a separate bootloader.

 

While you can continue with the strategy of having the app code involved do be very careful with this and be aware of any potential loop holes in the delivery/replacement process.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good insights Mr. clawson.

 

I do believe that my concept is resilient to power outage during bootloading because the prepared fw.bin file remains on SD card until successful (updated) main program starts. There is bigger danger that if the file is half prepared (decoded from hex to bin, and / or decrypted) power goes out. In that case I would copy half the file into the flash. I guess the solution would be to place another zero content file on the SD card just as a flag that preparation has been completed, and use  that  file as a trigger for the bootloading from the SD.

 

But as you said in the point 2, if I by mistake upload a blinky sketch that (last I checked) does not have a web server code, the further updates would be impossible. This would be a sort of soft bricking.

 

There is a low customer involvement plan B - in the case 2 (blinky) , customer receives updated code by email, and copies it to the SD card manually. Another option is to keep a backup server code ready on the SD card, and trigger the recovery process by copying and renaming a couple of files on the SD card.

 

Do you have any advice on where do I start in the attempt to roll my own bootloader (keeping in mind that my experience is limited to Arduino IDE and some Z80 on the ZX Spectrum)?

 

Thank you!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dariofil wrote:
some Z80 on the ZX Spectrum
A man of consummate taste!

 

(I wrote some of the firmware in the Spectrum +2A and +3 after our company (Amstrad) bought Sinclair ;-)

 

As to writing bootloaders - what language do you plan to use? If it's C and if more specicifically it is avr-gcc then the following is very useful...

 

http://www.nongnu.org/avr-libc/u...

 

In particular the example boot_program_page() function it shows there is a large part of what's required for actually writing the program data into the flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Much obliged Mr. clawson!

I will check it out with great interest after I get rid of some "real work".

Spectrum's firmware is what made it the best first home computer. I remember fondly the days of first consumer computers,

 

As for what I am planning to use - I don't know. Avr-gcc sounds good, and I will take your question as an advice, and look into it. I did install atmel studio 7 yesterday, but it seems that there is a bit of learning involved. I would kinda prefer command line compiler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dariofil wrote:
I did install atmel studio 7 yesterday,
That's just a Visual Studio wrapper around an avr-gcc anyway. The avr-gcc in it can be invoked from a command line too. In fact As7 has an entry for "Command Prompt" on the Tools menu (I think it is). If you use that you can just run avr-gcc at the DOS prompt.

 

Strange but true fact - when we took over "Sinclair" there was no documentation of the existing Spectrum 48K/128K firmware so most of our work was done with a copy of Logan/O'hara's Complete Spectrum ROM Disassembly ;-)

 

...for old times sake I just looked that up on Amazon:

 

https://www.amazon.com/Complete-...

 

$200!!! I should go up in the attic and dig out my rather tattered copy!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Could you please include the link?

 

Thanks!