ARM Cortex-M处理器的硬故障处理中的冗余代码 [英] Redundant code in hard fault handling of ARM Cortex-M processor
问题描述
来自 FreeRTOS.org , 关于调试硬故障&其他例外 在FreeRTOS上,在ARM Cortex-M3和ARM Cortex-M4微控制器上,我们可以使用以下代码来调试ARM Cortex-M硬故障-
From FreeRTOS.org, regarding Debugging Hard Fault & Other Exceptions on ARM Cortex-M3 and ARM Cortex-M4 microcontrollers, according to FreeRTOS guys we can use the following code in order to debug a ARM Cortex-M Hard Fault-
/* The fault handler implementation calls a function called
prvGetRegistersFromStack(). */
static void HardFault_Handler(void)
{
__asm volatile
(
" tst lr, #4 \n"
" ite eq \n"
" mrseq r0, msp \n"
" mrsne r0, psp \n"
" ldr r1, [r0, #24] <======== NOTE THIS LINE \n"
" ldr r2, handler2_address_const \n"
" bx r2 \n"
" handler2_address_const: .word prvGetRegistersFromStack \n"
);
}
现在,据我所知,标记的行无效,并且未在相应的prvGetRegistersFromStack
函数中使用:
Now, to my understanding, the marked line has no effect and is not used in the counterpart prvGetRegistersFromStack
function:
void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used. If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
volatile uint32_t r0;
volatile uint32_t r1;
volatile uint32_t r2;
volatile uint32_t r3;
volatile uint32_t r12;
volatile uint32_t lr; /* Link register. */
volatile uint32_t pc; /* Program counter. */
volatile uint32_t psr;/* Program status register. */
r0 = pulFaultStackAddress[ 0 ];
r1 = pulFaultStackAddress[ 1 ];
r2 = pulFaultStackAddress[ 2 ];
r3 = pulFaultStackAddress[ 3 ];
r12 = pulFaultStackAddress[ 4 ];
lr = pulFaultStackAddress[ 5 ];
pc = pulFaultStackAddress[ 6 ];
psr = pulFaultStackAddress[ 7 ];
/* When the following line is hit, the variables contain the register values. */
for( ;; );
}
pulFaultStackAddress
通过寄存器r0
由mrseq r0, msp
或mrsne r0, psp
传递,并且它是函数中使用的唯一参数.那么ldr r1, [r0, #24]
行有目的吗?
pulFaultStackAddress
is passed using register r0
by mrseq r0, msp
or by mrsne r0, psp
and it's the only argument used in the function. So is there a purpose for the ldr r1, [r0, #24]
line ?
推荐答案
CPU, OS and compiler makers often collude to produce a standard ABI (aka Abstract Binary Interface) for a particular platform. It's what allows you to link object files produced by different compilers/languages with your program. The calling conventions define how return values and parameters are passed between caller and called code, and other details required to allow inter-operable components written in different languages or compiled by different tools.
在汇编代码中看到的是应该由ARM联盟记录.为了从汇编程序成功调用C代码,您必须了解ABI.请注意,编译器编写者可以按自己希望的任何方式自由实现其调用约定,因此您的工作量可能会有所不同.这就是为什么我建议您检查C编译器文档的原因.大多数C编译器提供可配置的调用方案,有时平台ABI是默认的,有时不是.
What you are seeing in the assembler code is an ABI detail that should be documented by the ARM consortium. In order to successfully call into C code from assembler, you must understand the ABI. Note that compiler writers are free to implement their calling conventions any way they wish, so your mileage may vary. That's why I suggested you check your C compiler documentation. Most C compilers provide configurable calling schemes, sometimes the platform ABI is the default, sometimes it's not.
鉴于您的目标是RTOS,他们可能拥有自己的ABI,在这种情况下,他们可能会修改OSS编译器工具链,但很可能他们遵循ARM Cortex ABI.如果目标板没有可用的操作系统,则所有选择均不适用,您应咨询板制造商以获取相关文档(如果有).
Given that your target is an RTOS, it's possible they have their own ABI, in which case they probably modified an OSS compiler tool chain, but it is most likely that they follow the ARM Cortex ABI. In cases where the target board doesn't have any OS's available, all bets are off and you should consult the board maker for relevant documentation (if any).
这篇关于ARM Cortex-M处理器的硬故障处理中的冗余代码的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!