MPC5777C: Recover from exception IVOR1 to reset vector through Software Reset

[hemadri_payam]

Hi,

We are working on MPC5777C.
My application ends up in IVOR1 due to machine exception (eg: null pointer access)

We have JTAG interface and when we issue the software reset by setting the SSR bit in SIU_SRCR register.
It doesn't jump to the reset vector.

What is the procedure to be followed to jump to the reset vector through software reset (without using the POR/hardware reset).

Regards,

Hemadri

[lukaszadrapa]

Hi Hemadri,

using of SSR bit in the SIU_SRCR register is the right option. But it may be difficult to debug it because some debuggers are not able to catch this event. I'm sure it will work without debugger. If you want to use your debugger, an option is to add a breakpoint somewhere to startup code - this could work.

Regards,

Lukas

[hemadri_payam]

Hi Lukas,

Thanks for your response.

I tried the above scenario the you mentioned. But it does not return from the IVOR1.

I tried with the debugger and without the debugger with only JTAG. Still couldn't recover from the IVOR1.

If the code is executing without any exception, then with the software reset, the code starts executing from the beginning.

Regards,

Hemadri

[lukaszadrapa]

Hi Hemadri,

it seems there's some other problem. The software reset works unconditionally, it doesn't matter if it is triggered in an exception. Do you have some simple project to reproduce the issue?

Regards,

Lukas

[hemadri_payam]

Hi,

I have attached the elf file.

Hope this helps in debugging the issue

Regards,

Hemadri

[lukaszadrapa]

Hi,

but there's only endless loop in IVOR1 handler. I can't see a write to SIU_SRCR, so I can test it. Could you update the project/elf file?

Regards,

Lukas

[hemadri_payam]

Hi Lukas,

As soon as the code ends in IVOR1, I am manually setting the SIU_SRCR (Software reset) through the IDE (Trace32). And our understanding is it should reset the controller.

Let me know if the procedure that I am following is not as expected.

Regards,

Hemadri

[lukaszadrapa]

Hi,

well, the debugger has obviously some troubles to catch and recover this event. But if I test that using SW method only then it works as expected. Here is my minimalist code:

volatile unsigned int temp = 0;

void IVOR1_Handler(void)
{

    SIU.SRCR.R = 0x80000000;
}

int main(void)
{
    volatile int counter = 0;   
    xcptn_xmpl ();              /* Configure and Enable Interrupts */

    while(temp == 0){}   /* "user breakpoint" */
    temp = *(unsigned int*)0x3FFFFFD0;   /* generate bus error */

    /* Loop forever */
    for(;;) {       
           counter++;
    }
}

I used the "temp" variable as a "breakpoint" when I have to manually change the variable by debugger to continue (I don't want to rely on debugger and normal breakpoints). Then I read an unimplemented area to generate bus error. IVOR1 then just resets the device. I do not step the code, I just run it after manual modification of the "temp". When I stop it, it hangs in the "while" loop again and flags in SIU show that the device was reset by software reset.

So, this is not a problem of the chip, it's about debugger.

My recommendation is to find a way how to debug this event without debugger.

Regards,

Lukas