S32R274 ISR CONTEXT REVERT ISSUE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32R274 ISR CONTEXT REVERT ISSUE

Jump to solution
1,523 Views
lakshmikanth
Contributor III

Hi NXP,

In very need for Assistance...! 

- Platform: S32R274, DSPI MCAL Code and rest of application is Legacy. 

A) ISSUE:

1) During context restore from ISR to Function Context, somewhere the CPU GPRs and LR(Link Register) are being loaded with false return address instead of actual return address. Also as a side effect the LR and IP points to this undesired address (some function say Function5() ) causing infinite looping. 

B) BACKGROUND:   

1) A S32R274 based legacy project has a SPI Slave.

2) SPI MCAL is configured, generated, integrated on to this Legacy-Code. (Only SPI is MCAL)

3) Spi_AsyncTransmit( ) is called and the TX_FIFOs are Loaded and data is transmitted. (Total 8 Bytes (Channels) in a Job, Sequence) and for each byte Tx the below TCF (Transmit Completion ISR) is called.

4) The Rx'ed data is copied to Application buffers in "SPI TCF ISR" i.e Spi_Dspi_IsrFifoRx().

/* ISR Function Body Example */

ISR(Spi_Dspi_IsrTCF_SPI)
{
Spi_Dspi_IsrFifoRx(); /* Load Rx FIFO content to Application buffer.

EXIT_INTERRUPT();
}

/* End of ISR Function Body */

5) At the end of ISR Body i.e during execution of Prolog i.e ' } ' (Reverting the context), the CORE-1 CPU Registers are being loaded with false address which is further loader in to the LR (Link Register) and the function is unable to return to the actual caller function but instead Branches with Link to undesired function. (blr instruction)

6) And then it stays here with reason that: LR (Link Register) and IP (Instruction Pointer) points to the same address. 

In Brief: 

(Q) What might cause the LR (Link Register) to get loaded with "Undesired FunctionAddress" than with address of actual function to where the control shall RETRUN after ISR Context is finished.

(Q) Also what shall be the reason for LR and IP to be contain same address at a time causing undesired looping with in this undesired function.petervlna

MPC5xxxAutomotive Microprocessors / Microcontrollers & Tools s32r27 automotive‌ s32 registers s32 e200 isr spi communication e200z7 core

1 Solution
1,282 Views
lakshmikanth
Contributor III

Hi Stanislav Sliva,

- The Issue got resolved with peer help and the source of the problem was "using wrong ISR( ) macro expansion" which led to undesired form of ISR Prolog and Epilogue assembly code generation. 

Solution: 

- In GHS Project, We have added the macros in PREPROCESSOR Section:

(1) AUTOSAR_OS_NOT_USED

(2) USE_SW_VECTOR_MODE 

Result : [File effected: Mcal.h]

- Adding above 'Macros' ensured the use of the MACRO EXPANSION 'a' instead of expansion 'b'

- i.e: (a): #define ISR(IsrName)       void IsrName(void)

        (b): #define ISR(IsrName)       INTERRUPT_FUNC void IsrName(void)

            -  (where, "INTERRUPT_FUNC" expands to '_interrupt' and causes side effect in non-OS environment)

View solution in original post

0 Kudos
5 Replies
1,282 Views
stanish
NXP Employee
NXP Employee

Hi,

 Are you using S32DS for Power with MCAL drivers? As far as I know this setup has never been tested. There is no MCAL for e200 gcc available at the moment so I assume you have migrated a GHS or DIAB version.

Anyway according to the symptoms it seems like a stack frame gets corrupted for some reason.

I'd recommend you to check if the interrupt prologue/epilogue load/store sequence is correct. Where these routines come from? can you post the source file here?

Do you use nested-interrupts?

Sometimes such a behavior could be a result of stack overflow - I'd recommend you to increase your stack size in linker command file to quick check if this is a root cause of your issue.

Regards,

Stan

1,283 Views
lakshmikanth
Contributor III

Hi Stanislav Sliva,

- The Issue got resolved with peer help and the source of the problem was "using wrong ISR( ) macro expansion" which led to undesired form of ISR Prolog and Epilogue assembly code generation. 

Solution: 

- In GHS Project, We have added the macros in PREPROCESSOR Section:

(1) AUTOSAR_OS_NOT_USED

(2) USE_SW_VECTOR_MODE 

Result : [File effected: Mcal.h]

- Adding above 'Macros' ensured the use of the MACRO EXPANSION 'a' instead of expansion 'b'

- i.e: (a): #define ISR(IsrName)       void IsrName(void)

        (b): #define ISR(IsrName)       INTERRUPT_FUNC void IsrName(void)

            -  (where, "INTERRUPT_FUNC" expands to '_interrupt' and causes side effect in non-OS environment)

0 Kudos
1,282 Views
stanish
NXP Employee
NXP Employee

Lakshimi,

I'm glad you have been able to fix the issue and thanks for sharing the root cause on community.

Stan

1,282 Views
lakshmikanth
Contributor III

Thanks for the Support Mr.Sliva. 

0 Kudos
1,282 Views
lakshmikanth
Contributor III

Hi Stanislav Sliva,

Thanks for the response.

1) As you mentioned we are using GHS Tool-chain for POWER architecture.

2) Doubling the STACK SIZE was unable to solve the Issue currently.

In consideration with your suggestions, I will analyze more and will get back to you soon.

Request: If possible can you provide me with details (or) example files that: "Will there be any difference in implementing IVOR-1 Exception handler for complete Legacy Code vs Legacy Code with a MCAL Module well integrated into it?"

Thanks again.

0 Kudos