• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 22 subscribers
  • Views 5415 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

position independant code

Max red

I am trying to write the PIC. I wrote 2 programs in keil. 1 program is residing in the ROM (non PIC). And the second prgram (with-PI) I want to send over UART. I am trying to wrote the program and I also enabled /ropi and /rwpi options, and also tried oputputting the symbol definition file with --symdefs. Somehow I am not able to compile the PIC project. from my inderstanding "main()" is not required and from the startup file I am directly jumping to my_function(). The errors I am getting are pasted below:

toloadAPP.axf: Error: L6241E: toloadapp_startup.o(.text) cannot use the address of 'RWPI (R9 used as SB)' function add2num as the image contains 'USESV6 (R9 used as V6)' functions.
toloadAPP.axf: Error: L6248E: toloadapp_startup.o(.text) in PI region 'ER_RO' cannot have address type relocation to add2num in PI region 'ER_RO'.
toloadAPP.axf: Error: L6285E: Non-relocatable Load region LR_1 contains R-Type dynamic relocations. First R-Type dynamic relocation found in toloadapp_startup.o(.text) at offset 0xc.

The assembly file is as shown below:

                AREA    RESET, DATA, READONLY
               DCD     Reset_Handler             ; Reset Handler

                AREA    |.text|, CODE, READONLY

Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  add2num
                LDR     R0, =add2num
                BX      R0
                ENDP
               END

The C file is as below:

int add2num(int a, int b)
{
        return (a + b);
}

Anybody can point to the documentation with which I can proceed further?

Thanks

Parents Reply Children
  • 0 in reply to Andy Neil

    "Before getting too bogged down, are you sure that you actually need position-independent code at all...?"

    That is, of course, a very good question.

    The majority of users who implement boot loaders and field updating (potentially OTA - over the air) firmware updates do manage well without having position-independent code. Position-independence is most useful when playing with dynamically linked plugin modules (on "real" operating systems these modules are normally not position-independent but contains a fixup table where the loader have to patch the loaded module) but that is seldom needed for embedded devices.

    Having replaceable, dynamically linked, modules in an embedded device normally makes it too hard to test the software before shipping - each version of each plugin module adds multiplicatively to the total number of software combinations that needs to be tested.

  • 0 in reply to ImPer Westermark

    Hi.

    In an attempt to design a fault-proof software update mechanism to be used "in-the-field" by end customers, my plan was to use multiple application flash "partitions". When updating to a newer software release the oldest would simply be overwritten. The new one should only be activated after it had been verified that it was written successfully to flash. If this was not the case there should be a mechanism to fall back to the previous version.

    I assumed that I would require to generate position independent code. Is there another way to acheive what I describe above?

    And what is the common practice? Having a boot loader that can manage ONE instance of the "application" in flash?

    Thanks,
    Jonas

  • 0 in reply to ImPer Westermark

    Hi.

    In an attempt to design a fault-proof software update mechanism to be used "in-the-field" by end customers, my plan was to use multiple application flash "partitions". When updating to a newer software release the oldest would simply be overwritten. The new one should only be activated after it had been verified that it was written successfully to flash. If this was not the case there should be a mechanism to fall back to the previous version.

    I assumed that I would require to generate position independent code. Is there another way to acheive what I describe above?

    And what is the common practice? Having a boot loader that can manage ONE instance of the "application" in flash?

    Thanks,
    Jonas

  • 0 in reply to Jonas Romfelt

    To Jonas Romfelt:

    Maybe see these.

    http://www.keil.com/forum/13583/
    => search "Per Westermark", "1-Dec-2008 17:18 GMT" "But some basic methods to implement a boot loader are:"
    http://www.keil.com/forum/15092/
    http://www.keil.com/forum/18723/

  • 0 in reply to John Linq

    Thank you John for providing relevant links, very much appreciated! And thanks Per Westermark for the detailed forum posts.

    After reviewing my requirements once more I think that using a second temporary storage area while downloading is what I need, hence position independent code is out of scope for this time.

    Cheers,
    Jonas