We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all, I am trying to craft a (somewhat) complicated OVERLAY directive for the BL51.exe linker. Basically, the situation is this: I have one function that I am trying to add to the call tree, because it may get called in the future through function pointers, and I have another two functions that I am trying to designate as new root segments.
I can successfully do one or the other of these using one of the following:
OVERLAY(_caller_func ! _called_func) OVERLAY(* ! (_new_root_1, _new_root_2))
However, possibly through my own inability to count parentheses, I cannot combine these two directives so that both are executed. I get L201 (invalid command line syntax) fatal errors when using any variation of the following the I can think of:
OVERLAY((_caller_func ! _called_func),(* ! (_new_root_1, _new_root_2)) )
Any suggestions? -S
So this is not actually a problem at the moment, but may become so in the future?
No, the problem is now.. the base code that I am compiling will live on the device forever (there will be no way to modify this code in the future), while other code may be added remotely. There is nothing in the current code that calls this particular function, however it is functionality that needs to be exposed for the future added code.
You are basically fighting a fundamental limitation of the architecture here - so, rather than planning to fight the architecture, why not plan to switch to a more appropriate architecture?
The reasons are numerous and diverse, but suffice to say that it is not an option (if it helps you sleep at night, consider it a management decision and/or programmatic requirement).
It doesn't seem like I'm fighting the architecture that hard.. I have two independent issues, both of which have solutions provided explicitly in the Keil toolchain user guides. My issues even match up with their example use cases. It's just that I have both of them happening in the same program, and I can't get the syntax of the command right (maybe the linker isn't designed to be able to handle multiple cases, in which case I'll have to come up with a way to "trick" it into resolving one of the issues using the code itself).
Fair enough.
"have to come up with a way to 'trick' it into resolving one of the issues using the code itself"
sicking it in the initaliser of a table might do the trick...
"sicking it in the initaliser of a table might do the trick..."
That's what I'm thinking. Will lose a couple extra bytes of flash (not a big deal), and a couple cycles on boot (also not a big deal), will just have to make sure I document it well =P
should be "sticking", of course!