views:

83

answers:

2

I am developing a USB based bootloader for HCS08 family of micro-controllers. I have the bootloader code in assembly(which works fine for serial communication). I am calling a C functions for USB communication (Terminal<>Micro controller) from this assembly code. However, it seems that these C functions are not getting located in protected area ROM, I can see this in project.map.They are not in continuity with my bootloader code ie my bootloder code starts at F003, but these USB functions are at some ~1000-2000. My question is, how can I make these C functions to continue with the bootloader.asm code in ROM.

Here is the program flow:I have a C main function which jumps to the bootloader.asm on power up. Although, the bootloader.asm works fine but due to USB routines in non protected program ROM area, these are also ERASED and thereafter bootloader can not communicate with my terminal.

Any suggestion in this regard would be really helpful.

Thanks

+1  A: 

When you're producing code for an embedded system, you normally use a "linker/locator" instead of just a linker. The "locator" part means it allows you to set parameters that tell it what addresses the memory should be located at. Unfortunately, I can't tell you exactly how to specify that with the toolset you're using. If you tell us what toolset that is, perhaps somebody who (unlike me) has used it will know the details of specifying the address for the locator you're using.

Jerry Coffin
Yes, you may be right. I am using code warrior with processor expert. So, I think you are talking about .prm file. So, is it that on all these USB files I will say "#pragma CODE_SEG Bootloader_ROM" and in this prm file I will add "Bootloader_ROM" to a particular ROM memory.
Punit
@Punit: That sounds fairly reasonable, but with no knowledge of the tool set, it's impossible to say for sure.
Jerry Coffin
A: 

If you are using gcc+binutils, what you need is a custom linker script. This will give you explicit control over how your linked program is arranged in memory. The tricky part can be to find the standard script for your platform if you just want to make a few modifications. The script is generated when you build ld (part of binutils) and then embedded in ld. Often you can find it with strings ld and a search for "section" or other common linker script keyword.

The stock linker script can be very complicated to support all of the features of GCC, including debugging, C++ static initializers, read only data, relocation, etc.

Ben Jackson