ST意法半导体
直播中

张厉界

7年用户 232经验值
私信 关注
[问答]

SPC56EL60L3未处理的异常

大家好,
我正在使用SPC56EL60L3和SPC5Studio。
我注意到,有时我的应用程序卡住了,我发现,使用调试器,原因是触发了未处理的异常。由于它是随机发生的(或者,至少,我还没有发现任何模式),我无法弄清楚原因是什么。查看文档,我不清楚未处理的异常的原因是什么。任何人都可以分享一些细节吗?
谢谢。
亚历山德罗

以上来自于谷歌翻译


以下为原文




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

回帖(5)

刘鑫

2019-7-2 08:20:51
是的,亚历山德罗,
PC应处于未处理的异常状态
你应该在LR之前检查(断点之前)..
检查触发断言的汇编命令
全局变量和几个寄存器。
它是一个无限循环?或者腐败记忆?
0x1BE50到0x1C0AE之间有一个很大的分支
 最好的祝福
 二万

以上来自于谷歌翻译


以下为原文




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
举报

张厉界

2019-7-2 08:27:16
好,
是的,PC指向未处理的异常处理程序。
据我所知,我需要在指令处设置一个断点,该地址就在LR中包含的地址之前,对吧?
好。我不认为我不会在那里找到任何有用的东西。只有少数指令使用局部变量(也没有指针,也没有其他'危险'的东西)
通过文档,我找到了这个(第415页,参考手册RM0032):
'每个中断都有一个相关的中断向量地址,通过将IVPR [32-47]与相关IVOR中的地址索引连接得到(即IVPR [32-47] || IVORn [48-59] || 0b0)。结果地址是发生中断时要执行的指令的地址。 IVPR和IVOR值在复位时不确定,必须由系统软件使用mtspr初始化。 “
所以我去查看启动代码,我在'boot.s'文件中找到了这个:
 *异常向量初始化。
 
 * /
 .align 2
_ivinit:
 / * MSR初始化。* /
 e_lis%r3,HI(MSR_DEFAULT)
 e_or2i%r3,LO(MSR_DEFAULT)
 mtMSR%r3
 
 / * IVPR初始化。* /
 e_lis%r3,HI(__ ivpr_base__)
 e_or2i%r3,LO(__ ivpr_base__)
 mtIVPR%r3
 
 / * IVOR初始化。* /
 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'
 
 / *
 *未处理的异常处理程序。
 * /
 .weak _unhandled_exception
 .type _unhandled_exception,@ function
_未处理的异常:
 e_b _unhandled_exception
 ♯endif/ *!defined(__ DOXYGEN__)* /看起来像处理程序地址包含在IVOR 0-15和IVOR 32-34中的所有中断事件都链接到预定义的未处理异常处理程序。
这是否意味着如果其中任何一个源会引发其中断标志,该事件将触发未处理的异常处理程序?我猜是这样..
所以我需要检查谁正在发出一个中断标志(不应该这样做),对吧?
查看未处理的异常处理程序的汇编代码我认为我的应用程序被卡住的原因是因为处理程序只是一个无限循环..
如果更改了未处理的异常以便它只是从中断返回怎么办?这会让应用程序继续进行吗?
谢谢。
问候
亚历山德罗

以上来自于谷歌翻译


以下为原文




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
举报

刘鑫

2019-7-2 08:39:49
你好Allesandro,
是一种跟踪你的断言的方法。
通常在嵌入式软件中,最好停止代码而不是运行代码。
我怀疑(rtTaskUpdate_u8!= 0)或堆栈溢出时无限循环
不要犹豫,把你的代码发给我。
你使用RLA还是HAL?
在RLA& HAL,处理程序在ivor.s中
 最好的祝福
 二万

以上来自于谷歌翻译


以下为原文




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
举报

张厉界

2019-7-2 08:50:36
你好,Erwan,
谢谢您的回复。
请在下面找到一些更多细节。
我试图在unhandled_exception处理程序中放置一个断点,然后checl ESR resgister内容,我得到以下(设置了VLEMI和ST flsg):
LR寄存器的内容是0x000BE40,它指向while语句。
之前的断点表示可能导致异常的指令是0x000BE3C处的指令,正如您从混合模式程序集屏幕截图中看到的那样,它是irqIsrEnable()。
所以我猜这是异常的原因。
现在问题是:为什么irqIsrEnable()会导致这样的异常?
运行irqIsrEnable()是否需要满足任何先决条件?
回复你的意见:
''我怀疑是一个无限循环(rtTaskUpdate_u8!= 0)或堆栈溢出''
rtTaskUpdate根据变量的值在while循环结束时更新。
该变量由链接到定时器的ISR更新,以实现简单的调度程序。
总结一下:无限循环不太可能,堆栈溢出有更高的机会..我需要检查。
“你使用RLA还是HAL?”
我用RLA。
只是一个与发送我的代码相关的注释:由于代码不是公共域,我不能在这里共享整个模块代码。由于我的公司和ST之间已有NDA,我可以发送给您模块(通过私人电子邮件)。
感谢您的支持。
问候
亚历山德罗

以上来自于谷歌翻译


以下为原文




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
举报

更多回帖

发帖
×
20
完善资料,
赚取积分