Assistance Needed for Exception Handling in Application Code

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

Assistance Needed for Exception Handling in Application Code

1,350 Views
Suryav
Contributor I

 

I am currently working on injecting exceptions (i.e., simulating the occurrence of exceptions) and successfully handling them for the MPC5777C (e200z759CR) microcontroller. The GHS (Green Hills Software) probe is being used for building and testing.

 

So far, I have successfully injected and handled a few exceptions within my workspace. However, I am facing an issue while implementing this functionality in the application code. Specifically, I am encountering a machine check exception, which halts execution.

 

Regarding the handler implementation, the address of the instruction causing the exception is stored in the SRR0 register. To resolve the exception, I increment this address by 4 to point to the next instruction. The updated SRR0 value is then loaded into the Program Counter (PC) to resume execution. This approach aligns with the PowerPC architecture.

 

The exceptions I am working with include:

 

IVOR6: Program exception

IVOR13: Data TLB exception

IVOR5: Alignment exception

IVOR12: Floating-point round exception

IVOR1: Machine check exception

IVOR3: Instruction storage interrupt

IVOR32: SPE/EFPU/APU unavailable interrupt

I would appreciate your guidance on addressing the machine check exception issue during implementation in the application code. Please let me know if further details are needed.

 

Best regards,

Surya

 

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
Reply
2 Replies

1,328 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

There is a bulletin dealing with this address increment. Note that is not only related to SRR0 but SRR0, CSRR0, DSSR0, MCSRR0, according exception type:
https://www.nxp.com/docs/en/application-note/AN4648.pdf

 

davidtosenovjan_0-1736164912868.png

 

0 Kudos
Reply

1,301 Views
Suryav
Contributor I

Subject: Issue with Exception Handling in Application Code on MPC5777C(e200z759CRM)

Description:

I am encountering an issue with exception handling in the application code on the MPC5777C.

 

Initially, I tested the exception handling functionality in a sample workspace by integrating a few exceptions, and everything worked as expected. However, when I attempted to implement the same logic in the application code, the application stopped functioning properly.

 

Handler Code:

Below is the handler code I used:

 

mfspr r22, SRR0       

addi    r22, r22, 4

mtspr  SPRG2, r22     /* Save SRR0 in SPRG2 */

 

Later, the content of SPRG2 is stored in r4  

     /* Save SPRG2 in pc */   

 

 

In the workspace, the injected exceptions are directed to the function present in evb5777_bsp.adb for handing. 

 

The function is defined as follows:

 

function HaltExceptionHandler (vect: integer) return integer is

begin 

   return 0;

end;

 

 

Additionally, there are four exceptions categorized as "handled by Ada runtime":

 

Machine check

External interrupt

Floating-point unavailable

Decrement

 

The exceptions are directed to the procedure present in evb5777_bsp.adb for handing. 

 

procedure BSP_InterruptHandle is

   vect: integer;

begin 

   vect := integer ((INTC.IACKR AND 16#7FF#) / 4);  -- Read interrupt vector  

   -- Call interrupt handler if it exists  

   if (InterruptHandlers(vect).proc /= null) then  

      InterruptHandlers(vect).proc(InterruptHandlers(vect).arg);  

   end if;  

   INTC.EOIR := 0;  -- End of Interrupt  

end;  

 

 

Problem:

External Interrupt Exception Issue

 

The application generates external interrupt exceptions when data arrives from an external source. This external interrupt is one of the exception in the exception vector table, but they need to be ignored in this context.

 

The external interrupts occur frequently in the application code and it eventually leads to a machine check exception, causing the application to get stuck.

 

When a machine check exception arises, it does not reach the handler 

 

Instead, it results in most of the registers becoming "unreadable green hills probe error 12 (interrupt)" is coming

 

 

IMG_20250108_131315.jpg

0 Kudos
Reply