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

Self-contained C module or PIC

I need to write a self-contained module in C (is this even possible?) which is a part of a bigger app. This module should be loaded from some mass memory (most probably microSD card) to RAM and executed from there.
Actually, this code doesn't need to be position independent, because I can guarantee that the execution address in RAM is always the same. There is only one simple access function (kind of a data translator), it does not use any static variables, and can be (and, for now, it is) fully reentrant.

Of course, there is a dedicated load region for this module defined in the scatter file.
But:
- how to force the compiler to not use standard library function calls to the main app (as the adresses of library functions could change when we release new versions of the firmware)
or
- how to force the compiler to embed copies of library functions in the same region as the installable module, independent of what is in the main app,
or
- make the module ROPI, but then, how to call my access function from the main code? I thought, the only thing I need is a single const pointer to this function, placed in the first four bytes of the dedicated load region (still at an absolute address, remember?). I event created a section inside this region for this pointer only, declared it inside the my module and statically intialized it with the address of the access function. But the compiler complains about it, warning me like 'static initialization can cause link failure --ropi'.

After many hours of learning about this stuff I think, making the module ROPI does not change a thing, because there can still be calls to absolute addresses in the main app. Am I right?

Please help... I spent for now a few days looking for solutions, but found nothing really helpful ;( There are for real many questions about ropi or installable modules but still no precise answers...

Parents
  • As I wrote earlier, all things work fine if position independency is not used. Marking the load region as PI and compiling the .c and .s files with --ropi causes link failure, because of the DCD in the .s file

                    PRESERVE8
                    THUMB
    
                    AREA FIRSTDCD,DATA,READONLY
                    DCD exec_vector ; here is the problem
    
                    AREA |.text|,CODE,READONLY
    
    exec_vector PROC ; dummy test function
                    EXPORT exec_vector [WEAK]
                    add r0,r0,r0
                    bx lr
                    ENDP
    
                    END
    

    The linker sais "asm.o FIRSTDCD in PI region 'ER_IRAM1' cannot have address type relocation to exec_vector in PI region 'ER_IRAM1' "...
    This DCD gives me the address of the access function, and without that address, all this stuff is pointless ;( I would like an offset here instead the absolute address...
    A classic startup file does not compile as position independent, too. Is there a obvious solution that I don't get, or is it more complicated?

Reply
  • As I wrote earlier, all things work fine if position independency is not used. Marking the load region as PI and compiling the .c and .s files with --ropi causes link failure, because of the DCD in the .s file

                    PRESERVE8
                    THUMB
    
                    AREA FIRSTDCD,DATA,READONLY
                    DCD exec_vector ; here is the problem
    
                    AREA |.text|,CODE,READONLY
    
    exec_vector PROC ; dummy test function
                    EXPORT exec_vector [WEAK]
                    add r0,r0,r0
                    bx lr
                    ENDP
    
                    END
    

    The linker sais "asm.o FIRSTDCD in PI region 'ER_IRAM1' cannot have address type relocation to exec_vector in PI region 'ER_IRAM1' "...
    This DCD gives me the address of the access function, and without that address, all this stuff is pointless ;( I would like an offset here instead the absolute address...
    A classic startup file does not compile as position independent, too. Is there a obvious solution that I don't get, or is it more complicated?

Children
No data