Illegal address reset

[rahulkrishna]

Hi,

I have tried everything possible to figure out the reason for illegal address reset which i confirmed from the flag ILAF. Few problems with the issue is it is random so i cannot predict when it will happen. The following things i tried out

1. defining a function number in each and every function.

example

void function1(void)

{

functionnumber= 12;

}

void function2(void)

{

functionnumber = 13;

}

and so on i have written for all the functions and it crossed some 400, it includes the interrupts as well, but to avoid complexity i have not added in the xgate files. My processor is S12xEQ512 and the functionality is receive the CAN data from xgate and processed by CPU. As soon as the reset happens i am writing this function number into another variable and sending out on CAN when it again starts executing. Similarly i am also sending the stack size using the command asm STS stacksize. Now when i observed the results the stack size is within the range, but function number 8 out of 10 times indicates can rx interrupt isr number. once it indicated the timer overflow interrupt and once the i2c interrupt. But  i am not able to make out anything out of it. Please help me to figure out this issue. Any ideas how to resolve this with debugger or otherwise. Request suggestions for the same. 

[RadekS · Accepted solution]

Hi Rahul,

From your description, it seems that main issue is probably either

1. Some modifications on stack during ISR or
2. Some modifications of page register during ISR

The second option is more reasonable from my point of view.

For basic testing, you could store PPAGE (and other page registers) into the stack at every interrupt routine start and restore it at the end of the interrupt routine.

If you want to be sure and store all page registers, you could simply place command #pragma TRAP_PROC SAVE_ALL_REGS prior every interrupt.

Note: If you use TRAP_PROC SAVE_ALL_REGS, all page registers are saved, whether or not they are used in the interrupt procedure. If you use TRAP_PROC SAVE_NO_REGS, no page registers are saved. If only TRAP_PROC is given, all page registers specified with the -Cp option are saved. It is up to you to ensure that no other page registers are modified.

For ensuring that code and variables will be handled correctly, you should use -CpPPAGE=RUNTIME compiler command line option. The similar way you could define –CpEPAGE, -CpRPAGE,…

The next tip:

By default, when two variables are located in the same banked nondefault segment, Compiler/Linker supposes that they are on the same page and remove paging operations.

You could disable this optimization.

Go to project settings (Alt+F7), Compiler for HC12, Code Generation, check “Assume object are in the same page for” and change settings to “never for different objects”. Or you could simply add “-PSegObj” into Compiler Command Line Arguments.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[rahulkrishna]

Hi,

Thank you so much it seems to have solved the problem but i did not understand what is happening in the background. If possible can you please explain me what is happening? I will try to reproduce it again.

[RadekS]

Hi Rahul,

Which of my recommendations helped you?

The S12 core saves CPU registers on the stack during entering into interrupt routine and restores it during RTI instruction (Return from interrupt).

By default, S12 core does not save PAGE register(s). The typical ISR routines are stored in non-banked memory. Also, routines in banked memory which are called from these interrupt routines should not present any issue because instruction CALL save PPAGE register and RTC will restore it back. So, the most probable root cause is access to some constant/data in banked flash inside the interrupt routine.

This will change PPAGE register, but it will not return it back.

So, we have to manage that PPAGE will be saved at the beginning of ISR and restored at the end (manual save and restore, #pragma TRAP_PROC SAVE_ALL_REGS) or manage that access to data in paged flash will not modify PPAGE as a result (-CpPPAGE=RUNTIME).

The “-PSegObj” option disable optimization which removes “unnecessary” PPAGE handling for user segments. The compiler/linker assume by default that objects in the same user segments are on the same page.  So, if we, for example, copy data between two tables in the same user segment, it will be faster, but it could cause an issue when user segment is defined across several pages and these tables are not on the same page.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[rahulkrishna]

I have done both the changes so i am not sure due to which one the issue got resolved. I planned to do further analysis to find the actual line of code which causes the above issue to be 100% sure. I will update you in case if i can find something.

[rahulkrishna]

I am really clueless on this how to proceed.