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 prevent cross references between two sections

Is there a way to prevent cross references betweeen two sections, so that for example functions located in the .boot section can't call functions located in the .user section?
I'm developing a custom bootloader and I need it for obvious reasons.
I've digged through the scatter loading documentation but I didn't find the equivalent of the NOCROSSREFS() directive used in ld.
(I'm using armcc and armlink)

Parents
  • Per, Pier, thanks for your advice. We are switching from Microchip to ARM, and with Microchip we had developed a working bootloader source splitted in two parts: a bigger part, that after a "warm-up" period has remained unmodified for years, and a custom part, different for each project/microcontroller. This approached had proved to be fast and effective, and with no post-build overheads. The NOCROSSREFS() directive was enough to prevent calls between each section.

    Anyway I see that even if I use the ld file instead of a scatter file, the NOCROSSREFS directive is not supported: infocenter.arm.com/.../BABCJGDD.html
    I think that this comes from a lacking capability of the linker, so I have to study a different approach, like it or not.

Reply
  • Per, Pier, thanks for your advice. We are switching from Microchip to ARM, and with Microchip we had developed a working bootloader source splitted in two parts: a bigger part, that after a "warm-up" period has remained unmodified for years, and a custom part, different for each project/microcontroller. This approached had proved to be fast and effective, and with no post-build overheads. The NOCROSSREFS() directive was enough to prevent calls between each section.

    Anyway I see that even if I use the ld file instead of a scatter file, the NOCROSSREFS directive is not supported: infocenter.arm.com/.../BABCJGDD.html
    I think that this comes from a lacking capability of the linker, so I have to study a different approach, like it or not.

Children
  • I don't see it as a limitation when a linker behaves like 99+% of all linkers.

    Especially since most companies have an explicit or implicit policy that boot loaders must be separately version-controlled. And separately validated. And separately integrity-checked. All trivial when separate source code produces a separate hex file.

    And I don't see much need for studying to remove the end line from the intel-hex file with the boot loader and then do a trivial concatenation of this hex file with the hex file for the application to get a merged binary suitable for factory programming.

    When developing, I don't need to download any boot loader - it's already in the board. And the JTAG debugger would normally not need any boot loader to be there, since init scripts can duplicate boot loader state changes.