• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 1719 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

How to Link "aeabi" code to a fixed memory location

Detlef Weidner

Hi,

for the bootloader, integrated into the main project, I need to link the "__aeabi_uidivmod" to a fixed location within the bootloader section of my external flash memory.

How can I manage that?
I tried these expressions in the bootloader section of the scatter loading file, but it didn't cause something:

    aeabi_*    (+RO)
    *armlib/c_* (+RO)
    *armlib/h_* (+RO)
    *armlib*    (+RO)
    *armlib*

Any ideas?

BR
Detlef Weidner

Parents
  • 0 in reply to ImPer Westermark

    Thank you Per for your assistance,

    I think the best way was it to link all the needed libraries twice into two separete memory regions (bl and app), if armcc supports something like that. The advantage of handling with one project is the single file output for the target and the possibility to debug both simpler in the target.

    I just developed a single project solution in the past, using the gnu-arm compiler toolchain. Keil stopped the support of later versions of the gnu toolchain, so we were forced to switch to armcc. In the named older project I linked the libs and veneers to the bootloader section. Unfortunately the linker handling between both toolchains (.ld and .sct file) is very different.

    Maybe you are right and it's cleaner to make two targets. But I did not understand how to manage two separate targets for the same project in µVision. Could you give me some assistance? Independently of going a better and cleaner way it would be interesting to find out how to link the libraries and helper code to a fixed location.

    BR
    Detlef Weidner

Reply
  • 0 in reply to ImPer Westermark

    Thank you Per for your assistance,

    I think the best way was it to link all the needed libraries twice into two separete memory regions (bl and app), if armcc supports something like that. The advantage of handling with one project is the single file output for the target and the possibility to debug both simpler in the target.

    I just developed a single project solution in the past, using the gnu-arm compiler toolchain. Keil stopped the support of later versions of the gnu toolchain, so we were forced to switch to armcc. In the named older project I linked the libs and veneers to the bootloader section. Unfortunately the linker handling between both toolchains (.ld and .sct file) is very different.

    Maybe you are right and it's cleaner to make two targets. But I did not understand how to manage two separate targets for the same project in µVision. Could you give me some assistance? Independently of going a better and cleaner way it would be interesting to find out how to link the libraries and helper code to a fixed location.

    BR
    Detlef Weidner

Children
  • 0 in reply to Detlef Weidner

    In my experience (and honest opinion) uVision is close to useless for managing different targets, so I'd suggest that you just keep two different project files.

    I'm using separate projects for my bootloader and the application(s). This will make debugging the application slightly more cumbersome, but in my case I mostly debug via a serial port anyways. I am, however, using ulink/jtag for downloading to target (quicker than the serial port), and this is no problem, as my projects are configured to erase only the used sectors. When I download my application code to the target from within uVision, my bootloader is not affected/erased. When the target is reset, my bootloader runs first and starts the application. If I then want to debug the application from within uVision, it fails about 50% of the time (and sometimes uVision also crashes), since my bootloader obviously confuses the debugger.