This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Debugging a Usage Fault for an unaligned memory access

Hi,

I am experiencing a hard fault in Cortex M3 and bit#30 FORCED is set in the Hard Fault Status Register (0xE000ED2C). Referring to the Cortex M3 Technical Reference Manual:

[color="#0000FF"][30] FORCED Hard Fault activated because a Configurable Fault was received and cannot activate because of priority or because the Configurable Fault is disabled. The Hard Fault handler then has to read the other fault status registers to determine cause.[/color]

The value in the Configurable Fault Status Registers (0xE000ED28) is 0x01000000 which means that the bit#8 UNALIGNED is set in the Usage Fault Status Register (0xE000ED2A) . Again referring to the Cortex M3 Technical Reference Manual:

[color="#0000FF"][8] UNALIGNED When UNALIGN_TRP is enabled (see Configuration Control Register on page 8-25), and there is an attempt to make an unaligned memory access, then this fault occurs. Unaligned LDM/STM/LDRD/STRD instructions always fault irrespective of the setting of UNALIGN_TRP.[/color]

The value in the Configuration Control Register (0xE000ED14) is 0x00000200 which means that only bit#9 STKALIGN is set.

After reading through the relevant topics in this forum, I added the following code snippet to narrow down the problem.

[font="Courier New"]void hard_fault_handler_c(unsigned int * hardfault_args)
{
unsigned int stacked_r0;
unsigned int stacked_r1;
unsigned int stacked_r2;
unsigned int stacked_r3;
unsigned int stacked_r12;
unsigned int stacked_lr;
unsigned int stacked_pc;
unsigned int stacked_psr;

stacked_r0 = ((unsigned long) hardfault_args[0]);
stacked_r1 = ((unsigned long) hardfault_args[1]);
stacked_r2 = ((unsigned long) hardfault_args[2]);
stacked_r3 = ((unsigned long) hardfault_args[3]);

stacked_r12 = ((unsigned long) hardfault_args[4]);
stacked_lr = ((unsigned long) hardfault_args[5]);
stacked_pc = ((unsigned long) hardfault_args[6]);
stacked_psr = ((unsigned long) hardfault_args[7]);

printf ("[Hard fault handler]\n");
printf ("R0 = %x\n", stacked_r0);
printf ("R1 = %x\n", stacked_r1);
printf ("R2 = %x\n", stacked_r2);
printf ("R3 = %x\n", stacked_r3);
printf ("R12 = %x\n", stacked_r12);
printf ("LR = %x\n", stacked_lr);
printf ("PC = %x\n", stacked_pc);
printf ("PSR = %x\n", stacked_psr);
printf ("BFAR = %x\n", (*((volatile unsigned long *)(0xE000ED38))));
printf ("CFSR = %x\n", (*((volatile unsigned long *)(0xE000ED28))));
printf ("HFSR = %x\n", (*((volatile unsigned long *)(0xE000ED2C))));
printf ("DFSR = %x\n", (*((volatile unsigned long *)(0xE000ED30))));
printf ("AFSR = %x\n", (*((volatile unsigned long *)(0xE000ED3C))));

while(1);
}

__asm void Hard_Fault_Handler(void)
{
IMPORT hard_fault_handler_c
TST LR, #4
ITE EQ
MRSEQ R0, MSP
MRSNE R0, PSP
B hard_fault_handler_c
}[/font]

However, I am still not able to figure out and point out the instruction which is causing the issue .

Any help will be very much appreciated. I can provide more information if needed.

Thank you.

Regards,

Parents

Joseph Yiu over 11 years ago

Note: This was originally posted on 11th May 2010 at http://forums.arm.com

Hi Brown,

The order mentioned by the TRM is the sequence of stacking operation being carried out.
However, the order in terms of timing is separated from the order in term of address.
For locating the stacked PC value, please use the information based on figure 5.1.

Yes, it seems the fault in in your PendSV handler.

From the diagram you attached, assumed the screen is captured before the hardfault handler is executed:
LR = 0xFFFFFFF1 => Stacked was using MSP
MSP value is 0x2000F230 => Stacked PC is stored in 0x2000F230 + 0x18 = 0x2000F248
(Note : 0x18 = 24)

The stacked PC is 0x1FF00742 (approximately where the fault occurred)

The stacked xPSR is 0x0100000E (the fault happened inside PendSV exception because stacked IPSR is 0xE).
Bit 9 of the stacked xPSR is 0, so there is no padding at the stack frame. So the value of SP before the fault exception is 0x2000F230+0x20 = 0x2000F250. Otherwise, if bit 9 of the stack xPSR is 1, then the value of the SP before the fault exception is 0x2000F230+0x20+0x4 = 0x2000F254.

Note : PRIMASK is set.

If the faulting instruction is LDMIA R12!,{R4-R11}
and R12 is 0x1FF00D23, yes, this trigger an unaligned fault.
Multiple load store instructions can only handle aligned data transfers.

Are you using an OS? If yes which one are you using?
regards,
Joseph
Cancel
Vote up 0 Vote down

Cancel

Reply

Joseph Yiu over 11 years ago

Note: This was originally posted on 11th May 2010 at http://forums.arm.com

Hi Brown,

The order mentioned by the TRM is the sequence of stacking operation being carried out.
However, the order in terms of timing is separated from the order in term of address.
For locating the stacked PC value, please use the information based on figure 5.1.

Yes, it seems the fault in in your PendSV handler.

From the diagram you attached, assumed the screen is captured before the hardfault handler is executed:
LR = 0xFFFFFFF1 => Stacked was using MSP
MSP value is 0x2000F230 => Stacked PC is stored in 0x2000F230 + 0x18 = 0x2000F248
(Note : 0x18 = 24)

The stacked PC is 0x1FF00742 (approximately where the fault occurred)

The stacked xPSR is 0x0100000E (the fault happened inside PendSV exception because stacked IPSR is 0xE).
Bit 9 of the stacked xPSR is 0, so there is no padding at the stack frame. So the value of SP before the fault exception is 0x2000F230+0x20 = 0x2000F250. Otherwise, if bit 9 of the stack xPSR is 1, then the value of the SP before the fault exception is 0x2000F230+0x20+0x4 = 0x2000F254.

Note : PRIMASK is set.

If the faulting instruction is LDMIA R12!,{R4-R11}
and R12 is 0x1FF00D23, yes, this trigger an unaligned fault.
Multiple load store instructions can only handle aligned data transfers.

Are you using an OS? If yes which one are you using?
regards,
Joseph
Cancel
Vote up 0 Vote down

Cancel

Children

No data