P2020 QoriIQ Critical and NonCritical interrupts

[transporter]

Hi,

I am working on P2020 QoriIQ on vxWorks.

I have implemented exceptions handler for Noncritical interrupts.

When I have created  "System call" exception (defined Noncritical in PowerPC™ e500 Core Family Reference Manual)  by calling  via assembly "sc".  

In my handler I have noticed that Critical Interrupt Registers are updated (CSRR0 and CSRR1).

I would expect Noncritical interrupt registers(SRR0 and SRR1) will be updated for "System call" exception.

I have also checked the value of MSR register. MSR[CE] and MSR[ME] are masked.

Can you explain this behavior?

Thanks for help

[transporter]

Hi,

I have found bug in my exception handler. I have been returning registers in the wrong order.

Thanks everybody for help!

[transporter]

A system call exception sets SRR0/1. I have seen that CSRR0/1 are modified because NonCritical interrupts are immediately followed by the highest priority existing critical interrupt type( according to PowerPC™ e500 Core Family Reference Manual par. 5.10.2).

How can I disable or mask the following critical interrupt that causes reset on the target?

In my exceptions handler I make some prints only.

What can cause the debug exception?

In my MSR register MSR[DE] is set and also I have checked that DBCR0[IDM] is set also.

According to RM :

MSR[DE]      DBCR0[IDM]      Action

X                     0                     No action.

0                     1                     DBSR[UDE] is set.

1                     1                     DBSR[UDE] is set and a debug interrupt is taken.

Thank you for your help:)

[scottwood]

There are various things that can cause a debug exception -- see the debug chapter in the chip manual, and the contents of DBCR0.  What happens if you clear MSR[DE]?

[alexander_yakov]

Critical interrupts are: critical input, watchdog timer, and debug interrupts

I guess, in your case the reason of critical interrupt is debugger (if you are running under debugger control) or watchdog (if enabled and if you spend too much time in your handler)

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

[transporter]

Hi Alexander,

I make only some prints in my handler. It can not be watchdog.

Can you explain about critical interrupt of the debugger?

Thank you for help:)

[scottwood]

A system call exception sets SRR0/1.  It does not modify CSRR0/1.  Could you explain more about what you're seeing happen with CSRR0/1?  Was MSR[CE] masked the whole time from when you saw the previous value of CSRR0/1 to when you saw the new value?  Is it possible that software is writing to those registers for some reason?  Does the CPU execute code at the system call IVOR, or at some other exception entry point?  Is it possible some exception was taken when trying to execute code at the system call entry point?  Is it possible a debug exception was taken?

[transporter]

Hi Scott,

You are right a system call exception sets SRR0/1. I have seen that CSRR0/1 are modified because NonCritical interrupts are immediately followed by the highest priority existing critical interrupt type( according to PowerPC™ e500 Core Family Reference Manual par. 5.10.2).

In my exceptions handler I make some prints only.

What can cause the debug exception?

In my MSR register MSR[DE] is set and also I have checked that DBCR0[IDM] is set also.

According to RM :

MSR[DE]      DBCR0[IDM]      Action

X                     0                     No action.

0                     1                     DBSR[UDE] is set.

1                     1                     DBSR[UDE] is set and a debug interrupt is taken.

Thank you for your help:)