Topic : Compiler output generates a jump at incorrect address

Forum : ST7/STM8

Original Post
Post Information Post
May 10, 2016 - 8:12am
Matthieu Tardivon

Hello,

We are having some trouble with an executable generated from Ride. At first we noticed an unexpected reset from our MCU following a watchdog timeout. After a deeper study, we have found that when leaving a specific function, the program jumped at an incorrect address. And after study the function, we have seen that inside this function, two byte push were done but two word pop were done as well in a specific case, removing thus the return address from the stack. This second word pop is done because the function jumps at this address whereas it should jump at the instruction after.

To illustrate a little more the problem, you fill find the example in which the case occur. First of all, here is the version we are using:

Our compiler optimization is the following:

Here is the C code of the function:

What you have to know is that the input argument "test" has for value 0x0C, which will make the code enter the default case in the switch case call.

You must also know that when entering this function, the accumulator A is loaded with the value of the argument "test".

Below, you can find the assembly code generated for this function. As I was telling you above, "test" is pushed on the stack, variable byte "res" with value 1 is push on the stack. Then "test" is loaded in A from the stack. Then the switch case runs until we reach the line in blue.

This line in blue jumps to the address B03C which does a word pop, which implies that the next value on the stack is the return address and as you can see with the following instruction, an incorrect behaviour will occur when leaving hte function. According to me, the error lies in the fact that the jump should go to address B03D instead. Indeed, the word pop is useful in other cases of the switch case block.

This is mostly a bug report but my questions are the following:

- Is this already a known issue?

- If yes, is there a release which corrects this issue?

- Is the optimization responsible for this mistake?

- Is there a way I can be sure to avoid this issue by changing the project configuration and keeping my version? (When working with medical devices, updating to a new version requires an internal validation, which is quite a workload for the team)

Best regards,

Matthieu Tardivon

Replies
Post Information Post
+1
+1
-1
May 10, 2016 - 5:09pm
admin admin

Hello,

This is indeed a compiler optimization bug. It will be fixed in the next release.

The workaround is to switch off the optimization before the routine and to switch it on after.

#pragma o(2)

T_MonResult alarmDoTest( T_MonAlarm test )
{

...

}

#pragma o(3)

Regards,

St├ęphane

+1
0
-1
May 10, 2016 - 5:33pm
Matthieu Tardivon

Hello,

Thanks you for your support and for the hint, it is very helpful!

Best regards,

Matthieu Tardivon