LX51 overlapping code with no warnings/errors

The Linker doesn't care where the code comes from - if it spots some common stuff anywhere in the project, it can combine them...

It's not the addresses that need to make sense - it's the sequence of instructions that actually gets executed.

I agree with you, and we have examined the disassembly and noticed how the linker reuses assembly segments to reduce code size, however in this particular instance the linker does not seem to be doing that at all, here are some additional details that may come in useful:

a) We are linking against an .omf file which is a precompiled ROM
b) We make use of bank switching in both the ROM code and the final project

This is the sequence of events when the problem does not occur:

1) main() invokes an internal function timer_init() which is in bank #3. That function starts by performing an integer division, which gets translated into a call to C?UIDIV. This particular function, C?UIDIV, was compiled into the ROM (common area) and it is linked publicly through the .omf file
2) The first assembly instruction in timer_init() is an LCALL to C?UIDIV to perform the division. We can confirm that this LCALL is to the correct address for C?UIDIV by examining the precompiled ROM map file. We can also confirm when we step through the code that the division is indeed done and then the flow returns back to timer_init()

This is the sequence of events when the problem does occur:

1) Same as above
2) The first assembly instruction in timer_init() is also an LCALL but this time the address that follows it causes the flow to jump into the middle of function_x() in the common area. As per your suggestion, we just verified whether that could be an optimization trick used by the linker, but when we step through this code segment we see that function_x() completes as if it was called. This is not an integer division and the control flow never returns back to timer_init(), as it should if this was indeed an optimization.

Thanks,

Carles

The Linker doesn't care where the code comes from - if it spots some common stuff anywhere in the project, it can combine them...

It's not the addresses that need to make sense - it's the sequence of instructions that actually gets executed.

I agree with you, and we have examined the disassembly and noticed how the linker reuses assembly segments to reduce code size, however in this particular instance the linker does not seem to be doing that at all, here are some additional details that may come in useful:

a) We are linking against an .omf file which is a precompiled ROM
b) We make use of bank switching in both the ROM code and the final project

This is the sequence of events when the problem does not occur:

1) main() invokes an internal function timer_init() which is in bank #3. That function starts by performing an integer division, which gets translated into a call to C?UIDIV. This particular function, C?UIDIV, was compiled into the ROM (common area) and it is linked publicly through the .omf file
2) The first assembly instruction in timer_init() is an LCALL to C?UIDIV to perform the division. We can confirm that this LCALL is to the correct address for C?UIDIV by examining the precompiled ROM map file. We can also confirm when we step through the code that the division is indeed done and then the flow returns back to timer_init()

This is the sequence of events when the problem does occur:

1) Same as above
2) The first assembly instruction in timer_init() is also an LCALL but this time the address that follows it causes the flow to jump into the middle of function_x() in the common area. As per your suggestion, we just verified whether that could be an optimization trick used by the linker, but when we step through this code segment we see that function_x() completes as if it was called. This is not an integer division and the control flow never returns back to timer_init(), as it should if this was indeed an optimization.

Thanks,

Carles

a) We are linking against an .omf file which is a precompiled ROM
b) We make use of bank switching in both the ROM code and the final project

And you honestly expected that kind of contraption to work? Wow, you must be one brave coder.

And you honestly expected that kind of contraption to work? Wow, you must be one brave coder.

Honestly, we kinda were expecting it to work :) and in fact it did until very recently when we spotted this problem.

You still haven't said that there is any actual problem in the operation of the system

You still haven't said that there is any actual problem in the operation of the system

From my previous post:

2) The first assembly instruction in timer_init() is also an LCALL but this time the address that follows it causes the flow to jump into the middle of function_x() in the common area. As per your suggestion, we just verified whether that could be an optimization trick used by the linker, but when we step through this code segment we see that function_x() completes as if it was called. This is not an integer division and the control flow never returns back to timer_init(), as it should if this was indeed an optimization.

When the problem occurs, the flow never returns to timer_init() and the code basically vectors into space. This particular function, timer_init() is invoked from our main() but since it never returns from it, the software effectively hangs completely, not being able to proceed into the actual useful code that is run after the initialization functions (timer_init() being one of them).

Thanks!

Carles

I see.

I think Keil support is your only hope here; it's just too deep for people on a forum - with no sight of your system or your source code - to make meaningful, detailed analysis or comments.

Or maybe you need to get in an indepenent reviewer?

A forum can only really give general observations, like the fact that you are making this really, really, really complicated - and that is just asking for trouble!

When you get to a stage like this where you're having to pull every single trick in the book to the max to fight the limitations of the 8051 architecture, you really have to ask yourself whether it's worth the effort - or would it be less trouble to switch to another architecture that just doesn't have the limitations that you're fighting...

Sorry - no easy answer there!

I think Keil support is your only hope here; it's just too deep for people on a forum - with no sight of your system or your source code - to make meaningful, detailed analysis or comments.

Yep, as I think I mentioned earlier, we have already contacted Keil's support for this. However I thought I might as well give it a shot in the forums, although I am perfectly aware that not all information required has been made available.

When you get to a stage like this where you're having to pull every single trick in the book to the max to fight the limitations of the 8051 architecture, you really have to ask yourself whether it's worth the effort - or would it be less trouble to switch to another architecture that just doesn't have the limitations that you're fighting...

Yes, indeed I agree with you.

Thanks for your help!

Carles

a) We are linking against an .omf file which is a precompiled ROM
1) no .omf can exist in a ROM
2) if you have a .omf, you should have the source

Erik

1) no .omf can exist in a ROM

The .omf is not part of the ROM. When we build the ROM we generate an .omf file against which we link the full firmware release.

2) if you have a .omf, you should have the source

Yes, indeed, this is our own ROM. That code that is ROMed is frozen, and we continue developing the rest while linking with the ROM.
The .omf is used to be able to link against the ROM without having to build its source again. The .omf contains the public symbols defined by the ROM and their location in code space.

Carles

... it generates them.

What am I missing?

Erik

Oh yes it does!

The Compiler generates its objects in OMF;

The Linker accepts OMF files as input, and can generate an OMF file as its output.

:)