Function absolute address setting

[S_B_D]

Hi,

I am writing a HID bootloader. My first try will be a single project approach, this way the USB stack will be used only once.

Only USB interrupts are shared between the bootloader and application code.

In order to redirect all application interrupts to the Application code area I need to Fix all interrupt routines in an absolute flash address within the application code area.

I could not find the way to tell the linker to place a specific function in a specified flash location.

Your help is highly appreciated.

S.B.D  

[kef]

But you can place jump table (array of {JMP opcode, function address} structs) or vectors table (array of pointers) at fixed address. Also codewarrior has some support for ROM library, though I haven't tried it.

IMHO it's not a very good idea to do single project for both application code and bootloader code. Sharing code between application and bootloader can save some code space, but later you may have problems using different compiler switches, upgrading to more fresh compiler versions or changing compiler vendors. Possible calling conventions differences or something like that may break compatibility between application you just compiled and bootloader that is currently installed somewhere overseas. And then you will be forced to stop using shared bootloader functions and separate bootloader and application code.

Also, say bootloader uses some your own and some runtime routines from library, say A,B and C routines. Application uses routines B,C,D,E... Definitely bootloader should not erase routines ABC. But it is problematic to tell linker to force ABC to some dedicated segment. It is easy to #pragma and move functions defined in your code, but what about library functions and runtime routines? What is referenced by application part of your project files doesn't have to be placed in dedicated (not to be erased) segment, and what is called by bootloader part of your code has to be placed in dedicated segment... Is your solution to erase all the flash? But it is quite dangerous to do so. What if power fails after you emptied all the flash but before you finished flashing back bootloader part...

I prefer to 1) separate bootloader and application code, 2) secondary vectors table or jumptable to redirect vectors out of write protected bootloader flash. 3) For debugging purposes I concatenate bootloaders code with application code adding "HEXFILE boot.s19" line to application.prm. 

[S_B_D]

Thanks for the reply.

I understand your point regarding the dangers in a single project approach.

In a two project approach the only shared interrupt vector between the bootloader and the application codes is the USB interrupt, this vector will need to branch to the bootloader USB ISR routine or the Application USB ISR by some sort of fixed RAM variable known to both projects.

All other vectors will be redirected to the application space.

If I understand things correctly, I can not use the internal vector redirection mechanism and write protect the bootloader code. This is because the USB interrupt will be redirected to a section that needs to be re-written when uploading a new application code. this will erase the redirected interrupt vector, and the USB will stop functioning.Is this true?

I still don't understand how to write the redirected interrupt routines to a specific Flash address.

What is the syntax?

In Hi-Tech compilers it is just: void MyFunc(void) @ 0xaddress;

But in codewarrior the "@" is used for RAM fixing only.

Thanks,

S.B.D

[pgo]

Dear SBD,

I would consider developing a very cut down USB stack for the bootloader and using a simple polling loop to avoid any issues with the interrupt re-direction.  Considering the limited functionality and use of the bootloader any reduction in performance should  be OK.

I suggest you look at the USB bootloader examples available for the JMxx family for ideas. You can also have a look at how USBDM does something similar (although not as a HID).

I can very much agree with Kef about the need to separate the bootloader code & the main application.  It is very easy to inadvertently drag in a library routine that ends up is in the main body of the code and gets erased when re-programming!  The less that is in the bootloader the better.

Providing a vector table of entry points to your boot code allows the code to be conveniently separated.

bye

[S_B_D]

Hi,

I will go with a 2 project approach. My main concern that lead me to change my mind is future versions of codewarrior that may improve/change the code compression/ Linking algorithms and change the bootloader section completely. In a 2 project scenario this is irrelevant.

Can you please direct me on how to fix a subroutine in a specific absolute address?

I do not have the time/ USB know-how to patch CMX's HID stack for polling method.

Has it been done before? Will they support me if I try?

Thanks,

S.B.D