View topic - utility to generate a hex file for 4 bytes at given location

Search

utility to generate a hex file for 4 bytes at given location

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum

Author

Message

rgavrilov

Posted: Apr 07, 2012 - 07:39 PM

Joined: Jul 15, 2009
Posts: 72

Probably a dup, but I couldn't find the answer.

I need a utility that given a string of values and a memory location creates a hex file.

More details:

I want to program a 4 bytes long serial number for a device into flash.

Using AVR Studio 5 I get a hex file (out.hex).
I want to:
1. modify the output file to strip data that targets 0x1FF00-0x1FF04 area (this is where my SN is stored).
2. create a sn.hex file that generates a hex file that puts given on command line 32-bit value (my SN) at 0x1FF00.

So that I can generate no-sn.hex file when I compile my code, and send that to production team, and then give a utility (.bat file) so that production team can generate and program devices with unique SN.

there is this utility called srec_cat.exe I got with on of atmel's application notes that does what I need with .bin files, but I do not know how I can apply that to my hex (or .elf) files.

ezharkov

Posted: Apr 08, 2012 - 12:22 AM

Joined: Jun 21, 2005
Posts: 882
Location: Chicago area, USA

rgavrilov wrote:

there is this utility called srec_cat.exe I got with on of atmel's application notes that does what I need with .bin files

There is also a utility called avr-objcopy.exe, which can convert hex to bin and vise versa.

zbaird

Posted: Apr 08, 2012 - 12:45 AM

Joined: Aug 13, 2006
Posts: 6700
Location: Bellingham, WA - USA

Let me be sure I have this right, then I'll write it for you:

1. Command line interface OK
2. Hex file name in, serial number in, new modified hex file out

Correct?

Oh - and windows only, sorry

_________________
Chuck Baird
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org

westfw

Posted: Apr 08, 2012 - 02:25 AM

Joined: Jun 19, 2002
Posts: 955
Location: SF Bay area

You could put them on "no_sn.c" and actually compile them...

Code:

asm("  .section .version\n"

    "optiboot_version:  .word " MAKEVER(OPTIBOOT_MAJVER, OPTIBOOT_MINVER) "\n"

    "  .section .text\n");

// In the Makefile:

LDSECTIONS  = -Wl,--section-start=.text=0x3e00 -Wl,--section-start=.version=0x3ffe

%.hex: %.elf

   $(OBJCOPY) -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex $< $@

ka7ehk

Posted: Apr 08, 2012 - 02:33 AM

Joined: Nov 22, 2002
Posts: 12046
Location: Tangent, OR, USA

To the experts here -

This is something that I have wondered about, on this very subject.

One SHOULD be able to construct an Intel hex file containing the address where the data is to go, and a few bytes containing, for example, a serial number. Will the programmers AND the chips allow this to be written without messing with the rest of code space? Or, will it write a whole page containing the specified address. Will it erase that whole page first, before writing?

Jim

_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA

"The only thing standing between us and victory is defeat" P.G.Wodhouse in Wooster & Jeeves series

DocJC

Posted: Apr 08, 2012 - 02:47 AM

Joined: Dec 11, 2007
Posts: 6849
Location: Cleveland, OH

I don't qualify as an expert, but I'll give my two cents:

I don't know about the usual ISP programming of Megas and Tinies, but on the Xmega the Flash write writes one page at a time.

I wrote one version of programmer that read in each existing page first, into a buffer, updated the buffer with the new data, and then burned that page. It didn't do a clasic chip erase before burning a new program. Very cumbersome, very slow. If several lines of the Intel Hex File wrote to the same page then one did the Read/Overwrite/Burn several times. Very, very slow!

It wasn't clear to me that some/all of the tools out there do it this way. At least some, I believe, do a page erase followed by burning that page.

The obvious work around is to either write the serial number into the original source Hex file and change that line's check sum, and then burn the full file,

or

upload the specific flash page, overwrite the uploaded image, and then reburn it. (This would be slow)

As the Xmegas have EEPROM pages of (only) 32 bytes, vs 256 or 512 bytes for the Flash, it might be much faster to upload, modify, and burn an EEPROM page.

JC

david.prentice

Posted: Apr 08, 2012 - 08:30 AM

Joined: Feb 12, 2005
Posts: 16308
Location: Wormshill, England

Some ISP software will read all the Intel HEX lines into PC memory. And then send the appropriate SPI commands to the AVR.

Other software may just send commands in the order of the HEX file.

The first method allows you to 'overwrite' locations. It only needs to do the minimal number of SPI commands, so should be faster.

The second method would only work if any 'overwritten' bit locations go from 1 to 0.

I would be inclined to just write a C program that does what you want.
OTOH, it should be possible to do most of those jobs with avr-objcopy, hex2bin, bin2hex, sed, ...

David.

clawson

Posted: Apr 08, 2012 - 04:21 PM

Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

I still think the C compiler is the easiest:

Code:

#include <avr/eeprom.h>

char data[] EEMEM = { 0x37, 0x52, 0x97, 0x81 };

int main(void) {

 // this unused but just here to make a program that will build

}

If I build this (in my compiler I do nothing more than type "make") I get:

Code:

E:\avr>type test.eep

:04000000375297815B

:00000001FF

But if you really want to generate it standalone then first get the bytes into a file somehow (there may be easier ways that this!):

Code:

E:\avr>debug data.bin

File not found

-a 100

0CB3:0100 db 37, 52, 97, 81

0CB3:0104

-rcx

CX 0000

:4

-w

Writing 00004 bytes

-q

Then convert that to Intel Hex (also taking the opportunity to specify a start address):

Code:

E:\avr>avr-objcopy -I binary -O ihex --change-addresses 0x123 data.bin data.eep

E:\avr>type data.eep

:040123003752978137

:0400000300000123D5

:00000001FF

To change the address for the C solution to 0x0123 I'd need to have used --section-start=.eeprom=0x123

_________________

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum

AVRFreaks.net

Search