Create .rom [SOLVED - now mega1284P AVROSP bootloader]

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

I have a CVAVR application where CVAVR is producing .rom and .hex output files. I use the "Program the Chip" button after a Build All - I don't know whether it sends the .rom or .hex to the mega1284P (doesn't really matter I suppose...)

I want to automatically integrate a bootloader written in ASM, which Studio4 makes into a .hex file, into the download

So CVAVR's "merger data from a .rom file for FLASH programming" facility in the Compiler Options looks good.

But I don't have a .rom version of the bootloader - only .hex. How do I make a .rom from a .hex?

Alternatively it looks like I should be able to use CVAVR's Chip Programmer to load the bootloader .hex into the appropriate boot location and then, assuming I don't ever do a chip erase, I can leave it there and download new versions of the application "underneath" it in FLASH using the normal CVAVR programming facility?

Last Edited: Fri. Dec 17, 2010 - 05:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure I follow what you are asking. To get a bootloader into an AVR you use ISP to program its .hex file just as you would with any other program. Now it's true that once the bootloader is in the chip that the copies of the application code you then need to deliver to it (via RS232/UART I guess?) may well need to be in binary rather than Intel Hex and for that you'd usually use a hex2bin tool to convert the app.hex to app.bin (or app.rom if you prefer to call it that).

Cliff

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

I'm only talking about my iterative software development (I do understand bootloaders, honest!). So either I:

- use CVAVR to merge the bootloader .rom (supposing I had one) with the application .rom every time I (ISP via STK500) download a new version for iterative development

- load the bootloader .hex once (using CVAVR or Studio) and unless I do a chip erase, I can use CVAVR to (just) download the next version of the application "underneath" it (in memory terms). If I ever do a chip erase I will have to manually put the bootloader back in at the right flash location and then continue iteratively developing/downloading (just) the application.

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

You are missing the point of bootloaders. The bootloader is a completely separate program developed in complete isolation from the app. While developing (unless you have to) it's usually easiest to use your ISP programmer to download either the bootloader or the app or both into the flash. Only for the latter do you then need to join the bootloader .hex to the app .hex

You could develop and completely test the bootloader in complete isolation then (if you want) throw away your ISP programmer and for each build of the app code use the bootloader (and a PC terminal program?) to download the rebuilt app code into the app section of the flash. To protect the bootloader you can set the loc bits or simply put checks in it to prevent it programming anything above the BLS address.

Cliff

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

Quote:

But I don't have a .rom version of the bootloader - only .hex. How do I make a .rom from a .hex?

-- Open the chip programer
-- "Load flash" with the .HEX file
-- "Save flash" with the desired .ROM type/name.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Lee,

Is that just doing hex2bin ?

Cliff

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

clawson wrote:
You are missing the point...
With respect, I don't think so.

My bootloader is not for me - it is for the end users who will be able to update the application in the field using RS232 and the UART.

I will always use ISP via STK500 to load the app and bootloader for iterative development and testing (including testing that an end user can successfully update the app via the bootloader!) .

My bootloader is in ASM and I only have a .hex file for it.

My app is in CVAVR and I have both the .rom and .hex available if I need them.

CVAVR seems to offer the ability to automatically merge a .rom version of my bootloader with (presumably) the .rom version of the app before it downloads it to flash. But I don't have a .rom version of the bootloader. If CVAVR could merge the .hex version of my app and the .hex version of my bootloader then this thread would never have been started - but its merging capability only seems to be for .rom files...

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

Quote:

Is that just doing hex2bin ?

No, that's different. I don't know where the default CV .ROM came from. Probably from some universal format that Pavel was familiar with, like an EEPROM programmer?

000000:940C
000001:1082
000002:940C
000003:0000
000004:940C
000005:0000
000006:940C
000007:0000
000008:940C
000009:0000
00000A:940C
00000B:0000
00000C:940C
00000D:0000
00000E:940C
00000F:0000

One address, one word. ;) The filed get pretty big, relatively.

Note that there is also the .BIN option in "Save flash". It worked fine for me the few times I wanted to use it.

And between Load and Save you can edit the loaded images (flash or EEPROM) as well. That is sometimes handy when making a family of .EEP files for different app "profiles".

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Martin,

With the deepest respect you are missing the point.

When you are developing the app code it matters not a jot whether the bootloader is in flash at that time. Just switch off BOOTRST and develop the program as a "completely normal" development.

When the app development is complete and you have a final .hex (perhaps .rom if that's what the bootloader "eats") then program the bootloader back in via ISP, set BOOTRST and then deliver the .hex/.rom to the AVR via the bootloading mechanism.

Or is it the case that the app code is reliant upon functions in the bootloader? (obviously the converse could never be true).

Cliff

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

I thought Martin might have been creating the composite app+bootloader image that might be used when e.g. doing a batch of virgin chips.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

As I told him in a PM earlier today it's easy to make a composite app+BL in a single hex. Just:

copy app.hex+bl.hex joined.hex

then edit joined.hex and find the:

:00000001FF

in the middle of the file that marks the join point and delete that line.

PS maybe some of my confusion in this thread comes from the fact of not knowing what .rom is and why it would be used. Surely it must be possibly to convert the .hex built by CV into a .bin for use by a bootloader and otherwise ISP programmers use .hex so where does .rom ever come into the picture?

Last Edited: Thu. Dec 16, 2010 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

When you are developing the app code it matters not a jot whether the bootloader is in flash at that time.

Unless he share functions in the bootloader with the app..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

Unless he share functions in the bootloader with the app..

Do you think that might be the reason I said:
Quote:

Or is it the case that the app code is reliant upon functions in the bootloader? (obviously the converse could never be true).

;-) ;-) ;-)

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

I seem to read sloppily today, Cliff. Sorry.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

theusch wrote:
I thought Martin might have been creating the composite app+bootloader image that might be used when e.g. doing a batch of virgin chips.

Lee

That's pretty close to the mark actually - except I want to do it over and over on the same chip as I do my iterative development.

So Cliff's copy and manual editing is not appropriate (unless it can be automated) and even then I just want to press the "Program the Chip" button in CVAVR...

theusch wrote:
Quote:

But I don't have a .rom version of the bootloader - only .hex. How do I make a .rom from a .hex?

-- Open the chip programer
-- "Load flash" with the .HEX file
-- "Save flash" with the desired .ROM type/name.
I now have a .rom version of my bootloader :D It would be useful to indicate in the CVAVR manuals that this facility exists out-the-box.

So maybe I'm on my way now...

(so are CVAVR .rom files and GCC's(?) .bin files the same thing?)

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

If he needs to combine the application and bootloader into a single hex file he should use the srec_cat utility (part of winavr). Don't let the name confuse you, it will work with all hex file formats (with the proper arguments, use -I for each hex file). It's an interesting utility, it converted the output to records of 32 bytes per line from input files of only 16 per line (:10 to :20). Till I saw that I wondered why the output hex file (with the appication AND boot code) was SMALLER than my application hex file was!

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

Quote:

unless it can be automated

srec_cat (if you have access to a copy of WinAVR ;-)

And no, from what Lee says above, .rom is quite different from Intel .hex files and different from plain .bin binary files (which are not unique to GCC - binary is binary is binary)

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

At least there is a standard for hex files. I don't know if there is a standard for binary files (other than start a loc zero and one binary byte per byte till the end).

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

Quote:

if there is a standard for binary files

How could there possibly be?? There's no metadata in a .bin file, it's just the binary data and nothing more.

If there were a "standard" I guess it would say something like "the file will contain the binary data, err, that's all I can think of right now"

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

clawson wrote:
Quote:

if there is a standard for binary files
How could there possibly be?? There's no metadata in a .bin file, it's just the binary data and nothing more.
Not true. DEC had a 'binary' load format that used fixed length blocks with length, load address, and checksum fields. There were no delimiting characters, it was all position based.

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

Quote:

Not true. DEC had a 'binary' load format that used fixed length blocks with length, load address, and checksum fields. There were no delimiting characters, it was all position based.

But that was metadata - so it wasn't plain binary was it?

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

Here's the start of a CVAVR .rom file

000000:940C
000001:005E
000002:940C
000003:0000
000004:940C
000005:0000
000006:940C
000007:0000
000008:940C
000009:0000
00000A:940C
00000B:0000
00000C:940C
00000D:0000
00000E:940C
00000F:0000
000010:940C
000011:0000
000012:940C
...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Not true. DEC had a 'binary' load format that used fixed length blocks with length, load address, and checksum fields. There were no delimiting characters, it was all position based.
But that was metadata - so it wasn't plain binary was it?
Maybe. If metadata structures are defined as not needing delimiting characters then you are correct. Otherwise a binary file is just a raw dump that does not carry any info on where it came from. By binary (in DEC's case) I meant nothing was Ascii encoded.

Last Edited: Thu. Dec 16, 2010 - 04:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

..vs. the equivalent .hex

0C0000000C945E000C9400000C940000B6
:10000C000C9400000C9400000C9400000C94000064
:10001C000C9400000C9400000C9400000C94000054
:10002C000C9400000C9400000C9400000C94000044
:10003C000C9400000C9400000C9400000C94000034
:10004C000C9400000C9400000C9400000C94000024
:10005C000C9400000C9400000C9400000C94000014
:10006C000C9400000C9400000C9400000C94000004
:10007C000C9400000C9400000C9400000C940000F4
:10008C006162636465666768696A6B6C6D6E7071DA
:10009C0072737475767778797A001027E8036400A8
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vs the equivalent binary (OK, this doesn't 'type' well!):

D:\test>type test.bin
♀ö^ ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö
♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  ♀ö  abcdefghijklmnpqrstu
vwxyz ►'Þ♥d

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

OK - next problem...

Have made a bootloader from stevech's bootloader that compiles and responds with the BOOTIDSTRING when quizzed by AVROSP v1.9 - the latest I can find (and it's old - 2004).

However, AVROSP then tries to read the 'C:\Program Files (x86)\Atmel\AVR Tools\\PartDescriptionFiles\ATMega1284P.xml' and produces an error message

An error occurred:
  [Closing tag not found! Opening tag '' found, but not closing ''.]

I did some research here and there seems to be a problem with AVROSP and the newer XML part description files - is there a solution?

EDIT:what xml tags does AVROSP look for? I have an old atmega168.xml part description file that AVROSP is happy with and there's only a handful of tags in it (<10) - compared with 8500 lines of tags in the newer ATmega168.xml part description file. Maybe I can just find out the tags it needs and make a suitable 1284.xml file??

Last Edited: Thu. Dec 16, 2010 - 09:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Here's the start of a CVAVR .rom file

??? Are my posts invisible, to you and Cliff?

Quote:

It would be useful to indicate in the CVAVR manuals that this facility exists out-the-box.

??? again:
Quote:
You can Load or Save the contents of these buffers using the File menu.
Supported file formats are:
· Atmel .rom and .eep
· Intel HEX
· Binary .bin

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Partly yes - in the flurry of cross posts that happened this afternoon. I apologise - no offence intended.

Quote:
You can Load or Save the contents of these buffers using the File menu.
Supported file formats are:
· Atmel .rom and .eep
· Intel HEX
· Binary .bin
Yes I see that bit now. I still think it's a bit too subtly described - even if I had seen it earlier I wouldn't have twigged that it's actually a very clever facility that can load in one format and save in another....

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

OK - after some trial and error (and there still might be some error remaining) I seem to have what I want - an ATmega1284P bootloader that works with AVROSP and a relatively easy development technique using CVAVR. Maybe the following will help others (some small steps omitted - this is not a tutorial...)...

Get a copy of stevech's ASM bootloader (the one with RAMPZ handling in it) and modify it for the mega1284p:
- add .INCLUDE "m1284pdef.inc"
- change the .MACRO BOOTIDSTRING text to "AVRBOOT"
- change the MYORG .equ to SMALLBOOTSTART (bootloader is less than 512 bytes)
- change the EEMWE and EEWE bit names in the EEPROM I/O section to EEMPE and EEPE respectively
- change the response to "Block write command inquiry ('b')" to return 'N' as the bootloader doesn't seem to handle the AVROSP block mode EEPROM writes properly (AVROSP bombs with an error about the bootloader response not being correct)
- create a .hex version via Studio

In the CVAVR IDE, load the .hex into the Programmer and save it as .rom

In the CVAVR IDE, configure the project so that "after build" the contents of the bootloader.rom is merged with the application .rom before FLASH programming.

You can then iteratively develop and test your app, doing a single programming step that loads an integrated app and bootloader into the mega1284p from the "Program the Chip" button on the dialog box that appears after a "build all" (and if you get bored of continually loading the bootloader, just uncheck the option for merging the .rom bootloader file before programming)

Now to AVROSP, which an end user would use to update the FLASH and/or EEPROM via RS232 and the bootloader in the mega1284p, solving the problem of AVROSP not seeming to be able to read the new xml style part description files...

Use two DOS command lines to update flash and EEPROM respectively

avrosp -dATMega1284P -ifMyHexFile.hex -pf -e
avrosp -dATMega1284P -ieMyHexFile.eep -pe

...but you need to make a local ATMega1284P.xml file (read by AVROSP) that contains the barebones needed as AVROSP bombs when trying to read the new n'ty thousand line xml part description files. All I needed was

1310724096
128
$1E$97$05

...all on one line

It all works for me - YMMV.

Here's some extra odd keywords that might help this thread come up in searches:
ATmega1284 boot loader Codevision CodevisionAVR

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

Quote:

You can then iteratively develop and test your app, doing a single programming step that loads an integrated app and bootloader into the mega1284p from the "Program the Chip" button on the dialog box that appears after a "build all" (and if you get bored of continually loading the bootloader, just uncheck the option for merging the .rom bootloader file before programming)

But remind me again why you actually need the bootloader code in the AVR while developing the app?

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

Because it gives you the nice warm feeling that you have everything in place in the chip, you can do adhoc testing of the bootloader itself by exercising it from RS232 etc,

But between the lines, you're correct of course. Now I've sorted a >64k bootloader out (which seems a problem elsewhere at the moment) it's just another subsystem within the whole that is now sorted and it won't get much attention in the future. I'm already bored of waiting the extra time while CVAVR loads it each time - but at least I know how I can reload it any time I want.

So relative to my position when I started this thread, I'm significantly further forward in a) my mega168 ASM -> mega1284 C porting exercise b) my personal understanding

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

Quote:

But between the lines, you're correct of course

This was kind of the point I was trying (but failing :-() to make yesterday.
Quote:

(which seems a problem elsewhere at the moment)

I think you'll find that 64K..128K is not the issue it is 128K..256K that is exercising certain individuals.

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

Understood :)