SPC56EL60L3 - unhandled exception

alessandro2 · ‎2017-02-16

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 · ‎2017-02-16

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 · ‎2017-02-17

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 · ‎2017-02-17

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 · ‎2017-02-17

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 · ‎2017-02-18

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

Erwan YVIN · ‎2017-02-20

Posted on February 20, 2017 at 11:06

Hello Allesandro ,

_unhandled_exception:
 e_b _unhandled_exception�?�?

is a way to track your assert.

often in the embedded software, better to stop the code than running the code.

i suspect an infinite loop while(rtTaskUpdate_u8 != 0) or a stack overflow

do not hesitate to send me your code.

Do you use RLA or HAL ?

in RLA & HAL, the handler is in ivor.s

Best regards

Erwan

alessandro2 · ‎2017-02-20

Posted on February 20, 2017 at 15:46

Hello Erwan,

thank you for your reply.

Please find below some further details.

I tried to put a breakpoint inside the unhandled_exception handler and then checl the ESR resgister content, and I got the following (VLEMI and ST flsg are set):

the content of the LR register was 0x000BE40, which points to the while statement.

The breakpoint just before indicates the instruction which might have caused the exception is the one at 0x000BE3C, which, as you can see from the mixed mode assembly screenshot, is the irqIsrEnable().

So I guess this is the cause of the exception.

Now the question is: why would the irqIsrEnable() cause such exception?

Is there any precondition that need to be met to run irqIsrEnable()?

To reply to your comments:

''i suspect an infinite loop while(rtTaskUpdate_u8 != 0) or a stack overflow''

rtTaskUpdate is updated at the end of the while loop, according to the value of a variable.

That variable is updated by an ISR linked to the timer, to implement a simple scheduler.

To summarize: infinite loop in not likely, stack overflow has a higher chance.. I need to check.

''Do you use RLA or HAL ?''

I use RLA.

Just a note related to sending you my code: since the code is not public domain, I can't share the whole module code here. Since there's already an NDA between my company and ST, I could send you the module (via private email).

Thank you for your support.

Regards

Alessandro

Erwan YVIN · ‎2017-02-23

Posted on February 23, 2017 at 14:26

Hello Alessandro ,

VLEMI is VLE mode Instruction

SPE Unavailable

SPE Floating-point DataException SPE Floating-point RoundException Data Storage Data TLB Instruction Storage Alignment

ProgramSystem Call

ST is Store opration

Alignment

Data Storage Data TLB

check e200z4RM.pdf in google

i begin to understand your issue

you shouldinvestigate in the handler interruption in putting a breakpoint inivor.s (IVOR1,IVOR2 ..)

All the IVORx (0-32) except 4 and 10 are mapped into unhandled exception

you can investigating by updating your interruption handler

STEP 1:

you can patch these files to catch which IVORx is happening

Example below :

#=================================================
# Interrupt Vector Table
#=================================================
CoreVectorTable:
 .align ALIGN_SIZE
IVOR0_Handler:
 e_b . # IVOR0 - 0x1000 - Critical Input
 .align ALIGN_SIZE
IVOR1_Handler:
 e_b . # IVOR1 - 0x1010 - Machine Check
 .align ALIGN_SIZE
IVOR2_Handler:
 e_b . # IVOR2 - 0x1020 - Data Storage
 .align ALIGN_SIZE
IVOR3_Handler:
 e_b . # IVOR3 - 0x1030 - Instruction Storage
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

STEP 2:

put in a appriopriate place

 /* IVORx registers are 'hard-wired' in the e200z4*/
 /* IVOR0 Critical input (SPR 400) */
 mtivor0 IVOR0_Handler
 /* IVOR1 Machine check interrupt (SPR 401) */
 mtivor1 IVOR1_Handler
 /* and so on ..*/�?�?�?�?�?�?�?

Best regards

Erwan