burning elf file instead of S19 from bootloader?

[Leong]

Hi, I wonder if there is any example of loading ELF file instead of S19? the S19 file from an executable is 260kB and the ELF is only 60KB. What i wanted is to download the image to a section of on-chip flash of 52259 from the application and the bootloader checks it at boot time to determin if or not burn it as the new firmware. The S19 is just too big (and growing) to fit into the onchip flash and too slow to dump.

Thanks

Leong

[TomE]

Just convert the S19 to a binary file and load that.

Here's how to do that. Go to:

http://en.wikipedia.org/wiki/S19_%28file_format%29

If you don't want to write something yourself (which should take all of about 10 minutes) then follow the link to the "srecord" utility. It can convert S19 files to anything:

http://srecord.sourceforge.net/

What development environment are you using? It should have the option (or an "object convert" program you can run) that generates a pure binary file. It may already be generating a ".bin" or equivalent file. There should be some documentation that gives a "work flow" for getting generated files into the product that doesn't involve S19 files.

I've never heard of anyone burning an S19 file to FLASH before.

> download the image to a section of on-chip flash of 52259 from the application

I'm assuming that means you're sending the S19 file through a port (serial, ethernet, USB) to the Application and it is burning that to FLASH. The Boot can then load that S19 file to memory. So if the Boot is smart enough to convert the S19 file, why not move that "S19 to binary" code to the Application? That way you can still send it the S19 file and it can burn binary to the FLASH. Or (to speed up sending the code) move that conversion back to whatever is sending the S19 file. Make sure you add checksums as S19 has a checkum on each line and raw binary doesn't unless you add some.

Tom

[Leong]

Thanks Tom,

The CW can generate the bin file together with the Srec (along with elf). the Boot code i have currently already had the api to handle the S19 (from the freescale example). I guess I can rewrite the api to take binary (which is about half the size of S19, still over 100KB) as well.

Leong

[Leong]

btw, i guess i mistakenly thought elf is smaller footprint.. it's actually a lot bigger than s19. so the title of this thread really should be burning binary instead of S19, which i guess is managable... 

Leong

[TomE]

> S19 file from an executable is 260kB and the ELF is only 60KB.

> btw, i guess i mistakenly thought elf is smaller footprint.. it's actually a lot bigger than s19.

It contains all of the information that your debugger uses.

  942304 Mar  8 17:32 main.bin* 2709166 Mar  8 17:32 main.hex* 3175453 Mar  8 17:32 main.elf*

Do you have a "size" command to give something like:

$ m68k-elf-size *.elf   text    data     bss     dec     hex filename 516128  426176  936184 1878488  1ca9d8 main.elf 126048   35904   79036  240988   3ad5c boot.elf  19936    1088    2388   23412    5b74 memtest.elf

The "text" is the program code. The "data" is all initialised data in the project. The "bss" is all of the uninitialised data. The code takes "text + data" in FLASH, but "text + data + bss" in RAM, plus the stack and heap space.

You should have a close look at the "data" section. It might be a lot bigger than it needs to be. You might have a lot of statically initialised arrays or structures in your project. Depending on how smart the development environment is, these might generate huge blocks of zeros (dumb system) or in a smarter system may be compressed and expanded by initialisation code. Zero blocks get compressed down to almost nothing in these systems. What is your one doing?

Open your S19 file in an editor and see if there are large blocks of zero data in there. If there are, thenyou should be able to use the MAP file to convert the addresses in the S19 files back to the variable that are to blame.Then you can find them in the code (usually asking "why did I do something that stupid?"). You might even find large structures that you aren't even using any more or that don't need to be as big as they are.

If you do have some of these you can make your binary smaller (sometimes a lot smaller) by removing the static initialisation and writing a few lines of code to initialise these arrays and structures. This moves the data from "data" (which you have to store in FLASH) to "bss" (which you don't).

Tom