Banked calls

You built the code with "unresolved externals" warnings.

A banked application is still a single image, all linked together as one project. It just happens to be larger than 64KB and the compiler has to do more complicated things for a function call than just "LCALL <address>".

If you ignore the unresolved externals, you're ignoring the fact that the linker did not know the address for those routines. It has nothing to put in the CALL instruction. And I'd even bet that the code generator uses 0 as a placeholder for the address. So, each of your unresolved externals is likely CALLing 0 -- that is, the reset vector.

You need to build a complete image.

I'm not sure how a vendor is going to test the product with only half the code. But if they don't need the other half, perhaps you can just stub out all those functions with dummy functions in order to link a complete image. If vendors are supposed to supply their own routines for the other half of the code, then you need to reconsider the design.

If the image is to be statically linked, and banked with the usual methods, then you need to give them object files at least, so they can link their code with your base code.

If you don't want to do that, then you need to invent some sort of vector table, so that the base code can locate the addresses in the additional code at run time. (This is similar to a dynamically linked library.) If you have writable program store, then you could also dynamically load the extra code. That is, you store a file that includes the relocation information for the routines you need to call, and when you load the program, you patch all the calls with the proper target addresses.

It is possible to pass parameters to functions in a different bank.

You built the code with "unresolved externals" warnings.

A banked application is still a single image, all linked together as one project. It just happens to be larger than 64KB and the compiler has to do more complicated things for a function call than just "LCALL <address>".

If you ignore the unresolved externals, you're ignoring the fact that the linker did not know the address for those routines. It has nothing to put in the CALL instruction. And I'd even bet that the code generator uses 0 as a placeholder for the address. So, each of your unresolved externals is likely CALLing 0 -- that is, the reset vector.

You need to build a complete image.

I'm not sure how a vendor is going to test the product with only half the code. But if they don't need the other half, perhaps you can just stub out all those functions with dummy functions in order to link a complete image. If vendors are supposed to supply their own routines for the other half of the code, then you need to reconsider the design.

If the image is to be statically linked, and banked with the usual methods, then you need to give them object files at least, so they can link their code with your base code.

If you don't want to do that, then you need to invent some sort of vector table, so that the base code can locate the addresses in the additional code at run time. (This is similar to a dynamically linked library.) If you have writable program store, then you could also dynamically load the extra code. That is, you store a file that includes the relocation information for the routines you need to call, and when you load the program, you patch all the calls with the proper target addresses.

It is possible to pass parameters to functions in a different bank.

Thanks! This gives me an idea of what I'm doing wrong. I am going to look at building a library - that would probably be a better solution.