S-Record, Intel Hex and Binary Files

Posted on September 27, 2012 by Erich Styger

My earlier posts were around the Kinetis gcc compiler which comes with CodeWarrior for MCU10.3. MCU10.3 comes as well with the Freescale Kinetis compiler as in MCU10.2. In “S-Record Generation with gcc for ARM/Kinetis” I explored how to generate S19 or other output files with gcc. However, you only can produce one file format at a time. What if I need multiple formats or a different format. What if I need to do the same with non-gcc build tools? S-Records are usually easy as supported in the linker. Other formats need a bit more plumbing. So this post is how I can create and manipulate the different output formats, so I can use it with a bootloader.

S19 Files

The format of S19 (or S-Records) is explained in this Wikipedia article. To generate S-Records (or S19 files) e.g. with the Freescale Kinetis (non-gcc) is easy: there is a check box for it:

Generate S-Record Option

This passes the -srec option to the linker, and produces something like this:

S0030000FC
S3FD0000000080C00020DDBE0000CDAD0000F1AD0000F5AD0000F9AD0000FDAD000001AE000005AE000009AE00000DAE0000D9AD000011AE000015AE0000E5AD00005583000019AE00001DAE000021AE000025AE000029AE00002DAE000031AE000035AE000039AE00003DAE000041AE000045AE000049AE00004DAE000051AE000055AE000059AE00005DAE000061AE000065AE000069AE00006DAE000071AE000075AE000079AE00007DAE000081AE000085AE000089AE00008DAE000091AE000095AE000099AE00009DAE0000A1AE0000A5AE0000A9AE0000ADAE0000B1AE0000B5AE0000B9AE0000BDAE0000C1AE0000C5AE0000C9AE0000CDAE0000C9
S3ED000000F8D1AE0000D5AE0000D9AE0000DDAE0000E1AE000085B5000085B50000E5AE0000E9AE0000EDAE0000F1AE0000F5AE0000F9AE0000FDAE000001AF000005AF000009AF00000DAF000011AF000015AF000019AF00001DAF00006982000021AF000025AF000029AF00002DAF000031AF000035AF000039AF00003DAF000041AF000045AF000049AF0000997D00004DAF000051AF000055AF000059AF00005DAF000061AF000065AF000069AF00006DAF000071AF00004984000075AF000079AF00007DAF000081AF000085AF000089AF00008DAF000091AF000095AF000099AF00009DAF0000A1AF0000DC
S3FD0000041008B5DFF82C00006800280AD102F06EF80121DFF820000068016300F02FF902F075F8DFF810000068006BBDE808407047E828FF1F1400FF1F0021DFF808000068016370471400FF1F08B502F07BF8DFF860104A684AF22011C0F207014A434AF22011C0F20701081A10184108DFF840008160DFF83C008168DFF83400006881420AD2DFF82C0081684DF29000C0F203000918DFF81C008160DFF814008168DFF810000160DFF808008068BDE808407047D828FF1FF8B507460E46DFF8D0008078002860D0DFF8C4008178DFF8C400405C00F0020000282FD0DFF8B410DFF8AC0080780918087800F0FD000870DFF89C008078032100F00CFA39
....

X-Record (or Intel Hex)

The other option is to produce an X-Record file with passing an -xrec option to the linker:

X-Record or Intel Hex option

Actually that option naming is confusing, as that file format it produces s known as Intel Hex. Below is the beginning of the file produced for the same application as above, but in X-Record/Intel Hex format:

:020000040000FA
:4000000080C00020DDBE0000CDAD0000F1AD0000F5AD0000F9AD0000FDAD000001AE000005AE000009AE00000DAE0000D9AD000011AE000015AE0000E5AD00005583000075
:4000400019AE00001DAE000021AE000025AE000029AE00002DAE000031AE000035AE000039AE00003DAE000041AE000045AE000049AE00004DAE000051AE000055AE000030
:4000800059AE00005DAE000061AE000065AE000069AE00006DAE000071AE000075AE000079AE00007DAE000081AE000085AE000089AE00008DAE000091AE000095AE0000F0
:4000C00099AE00009DAE0000A1AE0000A5AE0000A9AE0000ADAE0000B1AE0000B5AE0000B9AE0000BDAE0000C1AE0000C5AE0000C9AE0000CDAE0000D1AE0000D5AE0000B0
:40010000D9AE0000DDAE0000E1AE000085B5000085B50000E5AE0000E9AE0000EDAE0000F1AE0000F5AE0000F9AE0000FDAE000001AF000005AF000009AF00000DAF000079
:4001400011AF000015AF000019AF00001DAF00006982000021AF000025AF000029AF00002DAF000031AF000035AF000039AF00003DAF000041AF000045AF000049AF0000B0
:40018000997D00004DAF000051AF000055AF000059AF00005DAF000061AF000065AF000069AF00006DAF000071AF00004984000075AF000079AF00007DAF000081AF000028
:2001C00085AF000089AF00008DAF000091AF000095AF000099AF00009DAF0000A1AF00000F
:020000040000FA
..........

Binary Files

Both above formats (S-Record and Intel Hex) are text formats. Another common format is the ‘binary’ format. In this format, the memory is just written byte by byte ‘as is’. So how can I generate such a format?

Burner

The solution is to use the burner utility which is an integrated tool for the 8/16bit (Freescale S08) tool chain. For S08 projects I can have a *.bbl (Batch Burner Language) file in my project to generate all kind of output formats. The syntax of the .bbl file is explained in the documentation, see this link. And documentation is not much-needed as there is a graphical user interface.

Hint: the Burner utility is really powerful and can be used in batch jobs to do all kind of manipulations on the files: converting between formats, extracting or merging files, and so on.

Burner Executable

The burner executable is located inside the MCU10.3 MCU\prog folder along with the S08 build tools. But it can be used for anything which produces as standard ELF format.

Burner executable inside MCU prog folder

Command Line Interface

The burner has a batch/command line interface. As burner.exe is a Win32 application, it can be used from the DOS shell or make files with the piper.exe in front to have it as Console32 application:

piper.exe burner.exe -h

Burner Command Line Interface

Graphical Interface

Starting the Burner.exe in graphical mode (e.g. double clicking with the Windows Explorer) opens it in a window mode:

Burner UI

I want to use the graphical mode to configure it to produce a script file for me, which I can use later to produce a binary file (or anything I want). For this I open the Burner Dialog:

Burner Input and Output Files

Here I specify my input and output files.

In the ‘Content’ tab I specify the format and memory range, plus what should happen for memory gaps (undef byte):

Burner Content Settings

The ‘Command Line’ tab shows the generated command line (batch burner language) source I could use in make files or as a post-build step:

Burner Command File

I can execute this directly. For this I switch back to the ‘Input/Output’ tab and press the ‘Execute’ button:

Burner Execute Button

This reports the status and result to the console:

Burner Console Output

Inspecting the generated binary file with EHEP shows this:

Binary File in EHEP Hex View

Automation: Post-Build Step

While the UI mode is fine to explore things, I want to use the burner as part of my build. For this, I use the same concept as I used in my CRC post: Build Steps.

But first I need to create a file with my commands in it. For this, I can copy-paste the commands from the Burner ‘Command File’ tab:

Burner.bbl with Macros

Note that I have replaced the absolute path with a macro (%ABS_FILE%). I want to have my script working relative to my project. I will pass that variable in the command line to the burner below.

Next is to set up a post build step. For this I’m using the following command line:

"${MCU_TOOLS_HOME}/prog/piper.exe" "${MCU_TOOLS_HOME}/prog/burner.exe" -F="${ProjDirPath}\Project_Settings\Linker_Files\burner.bbl" -Env"ABS_FILE=${BuildArtifactFileName}"

Post Build Step with the Burner

I use the piper.exe so the burner is running in command line mode. The -F option passes the command file in batch burner language. And the -Env option passes an environment variable I can use as above in my batch burner file.

With this, when I build my application, the binary (or whatever I do with the burner) is created at the end:

Burner Post Build in the Console View

And for my burner file I have the output (here a binary file) generated in my project:

Burner file and output file in project

Summary

I’m using the above approach for my S08, ColdFire and Kinetis projects and it works perfectly for me. Especially the flexibility and power of the burner utility is key for me. And it solves the usual build tool limitation that only one format is supported. With the burner I can manipulate the format, produce multiple formats or pretty much do whatever I want.

Happy Burning 🙂

55 thoughts on “S-Record, Intel Hex and Binary Files”

Robert Lewis on September 28, 2012 at 00:49 said:

Excellent article, I never understood all the possibilities before.

LikeLike

Reply ↓
- Erich Styger on September 28, 2012 at 07:18 said:
  
  Thanks :-). Especially the burner script language is providing a lot of flexibility. Too bad it is not seamlessly integrated for Kinetis.
  
  LikeLike
  
  Reply ↓
Daniele Missilone (@missilone) on October 29, 2012 at 17:02 said:

I love you Erich! :)))))))) (joking…)

LikeLike

Reply ↓
Daniele Missilone (@missilone) on October 30, 2012 at 11:36 said:

I have only a question: i try to burn a binary file from a .afx. I have the same command line of your example, but burner creates an incomplete file, the final part of afx is ignored and I find only FFFFFFFF……. so when I flash the bin on target, obviously, it doesn’t work! Could you help me?

LikeLike

Reply ↓
- Erich Styger on October 30, 2012 at 13:41 said:
  
  Have a look at the length parameter: maybe it is too short for your application and memory range?
  
  LikeLike
  
  Reply ↓
  - Daniele Missilone (@missilone) on October 31, 2012 at 09:29 said:
    
    I don’t think so, because the application is about 60 KB and the length parameter is 0x80000. It seems like “burner” can’t see the last part of code. I don’t know why (a bug, is possible?). If I generate s19 file with codewarrior and then convert it to bin it works.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on October 31, 2012 at 09:33 said:
      
      Yes, maybe this is indeed a bug. I suggest you send a service request to Freescale on this so they could look into this. And if you don’t mind: send me your file and burner file to the email address mentioned on the About page. If I have bandwidth, I can look into it.
      
      LikeLike
Daniele Missilone (@missilone) on October 31, 2012 at 12:20 said:

I sent you an email. Thank you

LikeLike

Reply ↓
Pingback: How (not) to Secure my Microcontroller | MCU on Eclipse
Dat Nguy on February 12, 2013 at 02:14 said:

Hi,
I’m also having problem with the last part of code. Was there a solution or workaround to this problem?

Thanks

LikeLike

Reply ↓
- Erich Styger on February 12, 2013 at 05:49 said:
  
  Hello, the solution is to increase the length parameter in the burner file. Or to create the S19 file from the ColdFire linker.
  
  LikeLike
  
  Reply ↓
Ramanujan on March 16, 2013 at 20:06 said:

Hi erich, i have one doubt can we convert two types of Motorolla S-records? Ex- S3 to S2 or vice-versa. If we convert it considering all checksum and everything will it work?
And try to flash it instead of S2 with the converted S2 will it really work?

LikeLike

Reply ↓
- Erich Styger on March 16, 2013 at 20:50 said:
  
  Hi Ramanujan,
  S2 is using 3 bytes for the address, and S3 4 bytes. So if you convert a S3 S19 record into one with S2, then you will loose the upper address bytes, so this typically will not work for a 32bit address space architecture. But for example is you have an S3 S19 file for a 16bit address architecture, you should be able to convert it into a S2 type file.
  
  LikeLike
  
  Reply ↓
  - Ramanujan on March 17, 2013 at 07:14 said:
    
    Thank you Erich for the fast reply. Ok i got the point imagine i just merge the data from one S-record to another .
    Ex ; if i copy only the data from S3 to S2 not the address and ill take care of the Checksum. So address will be as in S2 but only data will it work?
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 17, 2013 at 07:40 said:
      
      I think I do not get your point. The S2 and S3 records always have an address at the beginning. See http://en.wikipedia.org/wiki/S19_%28file_format%29.
      
      LikeLike
    - Ramanujan on March 17, 2013 at 07:50 said:
      
      Hi Erich,
      yes i do know that both adress bytes are different
      Take an example below. One is S2 and other is S3
      
      S21F”000000″XXXXXXXXXXXXXXX
      
      S321″00000000″DDDDDDDDDDD
      
      Resulted Merged file.
      
      S21F”000000″DDDDDDDDDDD
      
      Am keeping the address as it is and am copying only the data from S3 to S2.and even checksum is taken care while merging.
      Will this case works?
      
      And is there any separate length limits to S2 and S3 type records?
      
      Hope u got the point and scenario exactly.
      
      LikeLike
    - Erich Styger on March 17, 2013 at 15:27 said:
      
      Hi Ramanujan,
      yes, some tools are limited in the amount of code bytes they can read for each S19 file line. A safe number would be 32 bytes per line.
      If you are using the burner.exe mentioned in this article, you can configure this with an option.
      I suggest as well that you use that burner.exe to merge/convert S19 files, as this would be the most convenient way at least for myself.
      
      LikeLike
Pingback: Decoding S19 Files | MCU on Eclipse
Pingback: Serial Bootloader for the Freedom Board with Processor Expert | MCU on Eclipse
Allen Moore on August 21, 2013 at 23:56 said:

Is it possible to download the burner utility separately? Or is it only available as part of the (huge) CodeWarrior package?

LikeLike

Reply ↓
- Erich Styger on August 22, 2013 at 06:57 said:
  
  Hi Allen,
  it is not available separately. It is present as well in the classic (non-Eclipse) CodeWarrior version (e.g. for S08 or S12), but this does not make much difference. Plus the S08/S12 version is an older one, altough I believe not much has been changed (if anything at all).
  
  LikeLike
  
  Reply ↓
Pingback: New P&E OpenSDA Firmware v114 | MCU on Eclipse
vinod on March 7, 2014 at 11:17 said:

Hello Sir,
I was analyzing my SREC file to look at address 0x40C location which can sometimes secure.
I was analyzing a file of the SREC ,for e.g – “S1130040C9080000C9080000C9080000C908000068”.
I saw the wiki article – http://upload.wikimedia.org/wikipedia/commons/f/f1/Motorola_SREC_Chart.png
which looks at the 4 bytes (bytes 4,5,6,7) for the address –
In this case address is decoded as – 0040.
The last 2 bytes are check-sum, which means “C9080000C9080000C9080000C9080000” is the payload data. So how can I fine 0x040C here. Am a bit confused.
Am I looking at this right 🙂

Vinod

LikeLike

Reply ↓
Pingback: GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options | MCU on Eclipse
Carlos Mendoza on July 9, 2014 at 19:07 said:

Hi Erich,

Is there a standalone Windows utility that can be used to flash ELF or hex files to Kinetis L devices? Or a way for CodeWarrior to flash alternative ELF and hex files to an opened project?

I ask because we’re trying to use the same binary firmware files across two development teams sharing code using Git. I’ll explain myself. Team A builds the project and the compiler spits out ELF and hex files. They flash them (using CW’s built in tools and a Multilink FX) unto a custom KL46 board. Then Team A uploads the project’s non-derived files to a Git server. Team B then pulls these non-derived files and is forced to run CW’s build process to generate ELF and hex files. These binary and build files generated by team B have a different time stamp than those generated by Team A. In practice, however, both teams have binary files that produce the same behavior on their KL46 boards.

So this issue is more of a convenience factor to track the project’s development history.

The only way that I can think around it is to share a Zip folder containing Team A’s binary files and have Team B copy and paste these files unto the project’s FLASH folder. Of course, if Team B adds features and runs CW’s build process then new binary files are generated and thus they would need to be shared back with Team A.

Thanks in advance!

LikeLike

Reply ↓
- Erich Styger on July 9, 2014 at 21:12 said:
  
  Hi Carlos,
  you can use the ‘standalone flash programmer’ to program any file with CodeWarrior: https://mcuoneclipse.com/2012/04/30/flashing-with-a-button-and-a-magic-wand/
  Additionally, you can specify in the debug/launch configuration any file you want to flash. So you could share a binary in Git which both teams are using to flash, but this one is not actually built by the build process. There are several ways to do this.
  
  LikeLike
  
  Reply ↓
  - Carlos Mendoza on July 11, 2014 at 13:53 said:
    
    Thanks Erich!
    
    LikeLike
    
    Reply ↓
Carlos Mendoza on July 9, 2014 at 19:09 said:

…Otherwise, the derived binary files within the project’s FLASH folder would have to be added to the Git repository…

LikeLike

Reply ↓
Pingback: Recovering the FRDM-K64F Bootloader, or: Cloning the Program of a Microcontroller | MCU on Eclipse
pramod on February 10, 2015 at 14:18 said:

Hi Erich,
I want to write a 4 bytes value into hex file at a particular location during compiling. Of course, i can follow flash writing routines. But, is it possible to include this in compiler settings so that i can save a few CPU cycles during start-up? BTW i need it on kinetis with CW10.x.

Thanks,
Pramod

LikeLike

Reply ↓
- Erich Styger on February 10, 2015 at 14:37 said:
  
  Hi Pramod,
  as the hex file is generated by the linker, you cannot do this directly in the compiler. But you can have a constant piece of data in your code/compiled, which then will end up in the hex file generated by the linker. You might try out different things, but I think this is very doable.
  Erich
  
  LikeLike
  
  Reply ↓
Muhammad Saad Nawaz on June 8, 2015 at 18:42 said:

Hi Erich,
Please do a similar blog for Kinetis Design Studio as well.

LikeLike

Reply ↓
- Erich Styger on June 8, 2015 at 19:36 said:
  
  Hi Muhammad,
  most of that post applies to Kinetis Design Studio too, except that KDS does not have a burner.exe, and that the option to generate the files is in a different place. But for that part I have a post already: https://mcuoneclipse.com/2014/04/20/binary-files-for-the-mbed-bootloader-with-eclipse-and-gnu-arm-eclipse-plugins/ 🙂
  
  LikeLike
  
  Reply ↓
Marco Coelho on September 1, 2015 at 22:55 said:

Hello, Erich

I have followed your instructions for a MQX 4.2 project, but I failed to generate a .srec file. I got the following error from CodeWarrior 10.6 Builder: “mingw32-make: *** [mfs_usb_twrk20d72m.hex] Error 1.”

Do you know what could be causing this issue?

Thanks and regards,

Marco Coelho

LikeLike

Reply ↓
- Erich Styger on September 2, 2015 at 20:44 said:
  
  Hi Marco,
  what does the Console view show (the Console view shows all the command line commands and errors)?
  
  LikeLike
  
  Reply ↓
  - Marco Coelho on September 3, 2015 at 20:11 said:
    
    Hi, Erich
    
    Here it goes:
    
    **** Build of configuration int flash debug for project mfs_usb_twrk20d72m ****
    
    “C:\\Freescale\\CW MCU v10.6.4\\gnu\\bin\\mingw32-make” -j8 pre-build main-build
    C:/Freescale/Freescale_MQX_4_2/mfs/examples/mfs_usb/build/cw10gcc/mfs_usb_twrk20d72m/makedir.bat “C:/Freescale/Freescale_MQX_4_2/mfs/examples/mfs_usb/build/cw10gcc/mfs_usb_twrk20d72m/int flash debug”
    ‘ ‘
    ‘Executing target #8 mfs_usb_twrk20d72m.hex’
    ‘Invoking: ARM Ltd Windows GNU Create Flash Image’
    “C:/Freescale/CW MCU v10.6.4/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-objcopy” -O srec mfs_usb_twrk20d72m.elf “mfs_usb_twrk20d72m.hex”
    makefile:112: warning: overriding recipe for target `mfs_usb_twrk20d72m.elf’
    makefile:71: warning: ignoring old recipe for target `mfs_usb_twrk20d72m.elf’
    C:/Freescale/CW MCU v10.6.4/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-objcopy: ‘mfs_usb_twrk20d72m.elf’: No such file
    mingw32-make: *** [mfs_usb_twrk20d72m.hex] Error 1
    
    LikeLike
    
    Reply ↓
    - Erich Styger on September 3, 2015 at 20:52 said:
      
      Hi Marco,
      the problem is that mfs_usb_twrk20d72m.elf cannot be found. Does that file exist in your FLASH subfolder?
      And why do you have a ‘pre-build’ and a ‘main-build’?
      maybe you simply should delete the output (DEBUG? FLASH?) folder to get a clean state?
      
      LikeLike
Marco Coelho on September 3, 2015 at 22:14 said:

Hello, Erich

I tried to delete Debugger and Flash Folders and recompile the code as you suggested, but it didn’t work. Every time I enable Flash Image generation in CodeWarrior for any MQX 4.2 demo (I just tested for several other MQX 4.2 demos), I get this error and the *.elf file simply disappears.

Can you reproduce this problem on your side?

Marco

LikeLike

Reply ↓
- Erich Styger on September 4, 2015 at 08:32 said:
  
  Hi Marco,
  I’m not using MQX in my projects, so not easy for my to reproduce your setup. But what I had a problem with in the past with CodeWarrior is with having special options per file/folder as described here:
  
  Traps and Pitfalls: No Hex/Bin/S19 File Created with GNU?
  
  Maybe this is your problem?
  I know as well that some MQX projects uses special pre-build steps with custom ‘project of project’ settings, so this can be a source of problem too, not sure.
  
  LikeLike
  
  Reply ↓
Pingback: Merging S19 Files | MCU on Eclipse
david a on September 1, 2016 at 22:58 said:

Hi Eric,

would you know i can tell compiler not to use intel hex record types 02? and use 04 instead

thanks
david

LikeLike

Reply ↓
- Erich Styger on September 2, 2016 at 07:30 said:
  
  Hi David,
  I would use the SRecord tool (see https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/), it allows lots of intel hex customization, see http://srecord.sourceforge.net/man/man5/srec_intel.html.
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
Pingback: MCUXpresso IDE: S-Record, Intel Hex and Binary Files | MCU on Eclipse
Pingback: Using Eclipse to Program Binary Files to an Embedded Target | MCU on Eclipse
Psudonum on August 10, 2017 at 10:57 said:

Erich,

Is there any command in Srec that can generate .s19 file from txt file?
I mean if I simply create a txt file with Start Address of the Memory and some data, and pass it to the srec tool, will it generate s19 out of it?

If not, any other way to do this?

LikeLike

Reply ↓
- Erich Styger on August 10, 2017 at 18:18 said:
  
  Not that I’m aware of. An easier way would be to write a (intel) hex file instead and use that as input to the SRecord tool?
  
  LikeLike
  
  Reply ↓
  - Psudonum on August 24, 2017 at 14:07 said:
    
    Ok…that seems to be one way but a bit lengthy.
    Assume, I have data as 123456GCGH and that is to be written at address 0x7000.
    Do we have a command that takes two inputs 1. the above address and data 2. the existing S19 File. and Generate an O/P file that has merged the above data at mentioned address along with inputted S19 file.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on August 24, 2017 at 21:31 said:
      
      I think you can use the SRecord tool (see https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/) for this.
      Otherwise: use a simple perl/python script to generate some of the data and then combine it with the SRecord tool.
      
      LikeLike
Pingback: Converting a Raw Binary File into an ELF/Dwarf File for Loading and Debugging | MCU on Eclipse
Pingback: Converting Binary Files to Intel Hex Format with the SRecord Tool | MCU on Eclipse
SAIPRIYA SUBRAMANIAN on March 14, 2018 at 22:08 said:

Hi Erich,
I am trying to send a binary file through UART of a Kinetis part to the application section of an ATmega88 .I would like to know if there is any application note that gives me information as to how to transfer binary/hex files using UART to a target micro.
Thanks,

LikeLike

Reply ↓
- Erich Styger on March 15, 2018 at 05:58 said:
  
  There is really nothing special with sending binary/hex through UART. They are all data, and you can send any data through a UART. I hope this helps.
  
  LikeLike
  
  Reply ↓
Pingback: Generating Intel Hex Files with a given Length using srec_cat | MCU on Eclipse
Christian Saint on May 14, 2021 at 01:31 said:

You can import s19 files into hexworkshop and it will convert it over to binary.

LikeLiked by 1 person

Reply ↓
- Erich Styger on May 14, 2021 at 08:58 said:
  
  Thank you for that hint about Hex Workshop (was not aware of it)!
  
  LikeLike
  
  Reply ↓