Coercing Linker to Output Hex Formats

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

Linker outputs binary no problem, but refuses to output hex formats (Motorola S format and Intel extended hex), due to 3 separate code spaces required. Client requires hex output, so I have no choice.

Chip: ATmega 128
Linker: IAR XLINK, latest version
Code: Mixed C and assembler

The 3 spaces are: 1) the main executable, 2) bulk of boot section with its own vector table, and 3) "protected" page in boot area for another loader at a fixed address (last page - 256 bytes).

I've isolated the main app area from the boot area by dynamically switching vector tables, but the 2 boot-section areas must interoperate, so compiling them separately is not as simple.

If anyone has suggestions for a workaround, I'd appreciate it. I'm trying to stave-off writing the remaining C parts of the boot section (a lot of code) in assembler, as I'm far past the contracted time limit already.

TIA

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

2 solutions:

1) compile the 3 pieces of code separately, and then merge the hex files. Since these really are 3 separate applications anyway.

2) correct your segmentation, since you have apparantly forced 3 different address spaces instead of just one. This will require editing & correcting your XCL file.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Thanks for your quick reply, glitch.

>> 1) compile the 3 pieces of code separately...

Unfortunately, I can't compile all of them separately, even though ultimately they are to be programmed separately. Also, they are not 3 separate applications as is commonly the case with bootloaders.

It's somewhat complex, but there are actually 3 different loaders, 2 of which share some code. One is a typical bootloader, the one that gives no problems. Another is a later-added DPRAM-bound loader, and there was yet another request for a bootloader and DPRAM-loader programmer (yes, it sounds just as crazy to me as it does to you, but it was not my decision).

There is some programming code in the app area, with the actual page writer in the boot area (necessarily), which must be completely isolated from the plain bootloader in the boot area, so it can't be overwritten when the bootloader is reprogrammed remotely. There is some RAM shared between 2 of the programmers, which is what makes compiling them separately difficult.

>> 2) correct your segmentation, since you have apparantly forced 3 different address spaces instead of just one. This will require editing & correcting your XCL file.

Here are the relevant entries in one of the XCLs I've tried. I can't get the compiler to assign absolute addresses to the C routines, so I fudged this. If you have any ideas...

-Z(CODE)NEAR_F,HUGE_F,SWITCH,INITTAB,DIFUNCT,CODE=0-FLASH_LAST
-Z(FARCODE)FAR_F=BOOT_BASE-FLASH_LAST
-Z(CODE)BOOT_CODE_AREA=(BOOT_BASE+IVT_SIZE)-FLASH_LAST
-Z(CODE)LAST_BOOT_PAGE=(FLASH_SIZE-100)-FLASH_LAST
-Z(XDATA)EEPROM_N=0-FFF

I don't have enough time to revert to pure assembler, and I must ensure some code goes only into the LAST_BOOT_PAGE.

Thanks for your help

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

Can't you just program the chip and then read out the contents?

/* John Butera */

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

Hi pepsi,

That's one I didn't think of!

Unfortunately, the client needs to be able to recompile the code off-site, and then remotely upload it to the device with the AVR. In fact, that's what caused all the problems: the original serial bootloader (which they felt was insufficient), then the DPRAM loader for remote programming, and then the killer, another loader to reprogram the other 2 loaders! (in case of future modifications or bugs)

However, I'll use your idea to test the third loader, since I can move the chip into the test board, burn the binary with the JTAG, then pull the hex out.

Thanks

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

Linker commands you need:
-Ointel-extended,(CODE)=.hex
-Ointel-extended,(XDATA)=.eep
HTH

Cats never lie. At least, they do this rarely.

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

Privet Mikle (Pryvit if you prefer),

выдающийся! Worked perfectly; absolutely no problems. I see you have tamed XLINK before, since about this the documents are not clear.

благодарность (спасибі)