Crash when using RAMFUNCs

[dh1]

Hello

To optimize for performance, we move a set of functions to ITCM memory.
We do this with __RAMFUNC(RAM2)

Now we randomly experience crashes with this. Randomly means, we change anything somewhere in the firmware, not necessarily in a RAM function, recompile and rerun it, and then the problem appears.

Often, we then have to add one more function to RAMFUNC, or remove one, and the problem disappears.

When we debug, we see that the program comes to a "veneer", and there instead jump to the respective function, go on to the next veneer and execute that function call. Then it crashes.

This is the call of the function TCA9555_WriteOutput

Then I do instruction stepping. One step later:

Three steps later

I'd expect it to go to the function in RAM now, but instead it goes to the next veneer:

Then I'm stepping further, and it even goes to the next veneer:

This call is then actually executed (which is not the actual program flow at all):

I can't make any sense of this.

I attached the .map file.

Thanks in advance and regards,

Daniel

[dh1]

Hi Felipe

Yes I have seen this section in the manual. But to me, it says that the linker automatically creates these "veneers" and I don't have to do the calls via function pointer.

Only to work around the debug problem, calls via function pointers are necessary.

Or do I get this wrong?

The problem we have does not only happen when we debug, it also happens with a normal run of the firmware.

We have a lot of functions moved to RAM. It would be very ugly if we have to do all these calls via function pointers?

Thanks and regards,

Daniel

[FelipeGarcia]

Hello Daniel,

You are correct. The veneers are automatically created by the linker. However, according to your description you are stepping in to your function in RAM. This sometimes will cause you issues, the recommended workaround in the one mentioned in my previous reply. 

Best regards,

Felipe

[FelipeGarcia]

Hello Daniel,

Please check the below extract from MCUXpresso IDE User Guide that explains the behavior you are facing.

Due to the distance in the memory map between Flash memory and RAM, you will typically require a “long branch veneer” between the function in RAM and the calling function in Flash. The linker can automatically generate such a veneer for direct function calls, or you can effectively generate your own by using a call via a function pointer.

One point to note is that debugging code with a linker generated veneer can sometimes cause problems. This veneer will not have any source level debug information associated with it, so that if you try to step in to a call to your code in RAM, typically the debugger will step over it instead.

You can work around this by single stepping at the instruction level, setting a breakpoint in your RAM code, or by changing the function call from a direct one to a call via a function pointer.

Hope it helps!

Best regards,

Felipe

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored.

Please open a new thread and refer to the closed one, if you have a related question at a later point in time.

------------------------------------------------------------------------------