SPC56EL60L3 - unhandled exception

[alessandro2]

Posted on February 16, 2017 at 11:57

Hello everyone,

I'm working with a SPC56EL60L3 and SPC5Studio.

I noticed, sometimes my application got stuck and I found out, using the debugger, that the cause was an unhandled exception being triggered. Since it happens randomly (or, at least, I don't have identified any patterns, yet), I can't figure out what the cause is. Looking at the documentation it is not clear to me what the cause for unhandled exception could be. Can anyone share some details on this?

Thank you.

Alessandro

[Erwan YVIN]

Posted on February 16, 2017 at 14:34

Hello Alessandro ,

you should check your LR (Link Register) and check your call stack

and try to put a breakpoint just before your Link Register in the assembly code. (on the debugger)

    Best Regards

                       Erwan

[alessandro2]

Posted on February 17, 2017 at 09:38

Hello Erwan, 

thank you for your reply.

Ok, I can check my call stack, using the debugger, when I find my application stuck.

What's not 100% clear to me is where    to place the breakpoint. I don't know what instruction is causing the exception, so where do I place it?

Thank you.

Alessandro

[alessandro2]

Posted on February 17, 2017 at 11:25

OK,

this is the CPU status, while the application is stuck.

The link register contains address 0x0001BE50, which links to the following code:

I don't know if this information is useful..

To find what cuased the exception, shouldn't we be looking at what happened before the exception was raised?

Alessandro

[Erwan YVIN]

Posted on February 17, 2017 at 11:56

Yes , Alessandro ,

The PC should be in unhandled exception

You should check just before the LR (a breakpoint before) ..

check the assembly command which triggers the assert

global variable and several registers.

is it an infinite loop ? or maybe corruption memory ?

there is big branch between 0x1BE50 to 0x1C0AE

           Best Regards

                              Erwan

[alessandro2]

Posted on February 18, 2017 at 13:59

OK,

yes, the PC points to the unhandled exception handler.

As far as I understand I need to put a breakpoint at the instruction which address is just before the one contained in LR, right?

Good. I dont think I'm not goingo to find anything useful there. Just few instructions working with local variables (nor pointers, neither other 'dangerous' stuff)

Going through the documentation, I found this (page 415, reference manual RM0032):

'Each interrupt has an associated interrupt vector address, obtained by concatenating IVPR[32–47] with the address index in the associated IVOR (that is, IVPR[32– 47] || IVORn[48–59] || 0b0). The resulting address is that of the instruction to be executed when that interrupt occurs. IVPR and IVOR values are indeterminate on reset and must be initialized by the system software using mtspr. '

So I went to look at the startup code, and I found this, in the 'boot.s' file:

* Exception vectors initialization.

*/

.align 2

_ivinit:

/* MSR initialization.*/

e_lis %r3, HI(MSR_DEFAULT)

e_or2i %r3, LO(MSR_DEFAULT)

mtMSR %r3

/* IVPR initialization.*/

e_lis %r3, HI(__ivpr_base__)

e_or2i %r3, LO(__ivpr_base__)

mtIVPR %r3

/* IVORs initialization.*/

e_lis %r3, HI(_unhandled_exception)

e_or2i %r3, LO(_unhandled_exception)

mtspr 400, %r3 /* IVOR0-15 */

mtspr 401, %r3

mtspr 402, %r3

mtspr 403, %r3

mtspr 404, %r3

mtspr 405, %r3

mtspr 406, %r3

mtspr 407, %r3

mtspr 408, %r3

mtspr 409, %r3

mtspr 410, %r3

mtspr 411, %r3

mtspr 412, %r3

mtspr 413, %r3

mtspr 414, %r3

mtspr 415, %r3

mtspr 528, %r3 /* IVOR32-34 */

mtspr 529, %r3

mtspr 530, %r3

se_blr

.section .handlers, 'axv'

/*

* Unhandled exceptions handler.

*/

.weak _unhandled_exception

.type _unhandled_exception, @function

_unhandled_exception:

e_b _unhandled_exception

♯ endif /* !defined(__DOXYGEN__) */

Which looks like all interrupt events which handler address is contained in IVOR 0-15 and IVOR 32-34 are linked to the predefined unhandled exception handler.

Does this mean that if any of those sources would raise its interrupt flag, that event will trigger the unhandled exception handler? I guess so..

So I need to check who's rasing an interrupt flag (not being supposed to do so), right?

Looking at the assembly code of the unhandled exception handler I think the reason why my application gets stuck is because the handler is just an endless loop.. 

And what if changed the unhandled exception so that it just returns from interrupt? Would that allow the application to go ahead? 

Thank you.

Regards

Alessandro