Hi all,
I have this funny yet annoying issue.
I was developing a USB hardware, with composite device function (HID+MSD), containing cryptographic algorithm implemented in assembly and a lot of logical code in C in the firmware.
I was using SAM3S8B and everything was good.
Now is the time for bulk production of this hardware, But I noticed if I reduce the RAM usage to under 32k I may use SAM3S2A with a considerable cheaper price and I did it.
The problem is:
The firmware works fine in my own debug board using SAM3S8B but when testing it on a SAM3S2A or 4A, it randomly causes hard fault exception.
The code size is CODE = 82512 RO = 4596 RW = 300 ZI = 28580 (4k stack size included while estimated stack size = 3k)
The debug boards are the same which can contain both 48 pin and 64 pin SAM3S micro controller.
The funny part still remains:
I had 2 static libraries in my project using SAM3S8b configuration in their own projects, which I fully changed them as well as the main project configuration and SYSTEM and STARTUP files to SAM3S2A. The annoying point is whether I change these configuration or not the result is the same:
It works fine in a board with SAM3S8B even using SAM3S2A configuration, but none of the configurations work for SAM3S2A or 4A.
is there anything I'm missing here? may someone help me?
uVision version = 4.70.0.0 debugger used = keil ulink2
Then focus on debugging the Hard Fault.
Does the new part have a larger vector table, FPU fault?
Thanks for your reply. I did not check if it has a larger interrupt vector table, including floating point faults, or not.
But the fact that the sam3s core is the same and that Atmel provides only one EK for SAM3S devices(sam3s2-EK), here: www.atmel.com/.../sam3s.aspx led me to think that debugging the hard fault may be useless.
But now that you mention it again, I think it worth working on.
Hi the result of debugging the hard fault, if can be named debugging, is as follows:
I set a break point in hard fault handler. When hitting it for the first time the LR shows 0xfffffff9 so i think i can't trace the source of the fault.
my (keil's) hard fault handler:
HardFault_Handler\ PROC EXPORT HardFault_Handler [WEAK] B . ; break point is here ENDP
The vector tables are the same and there is no FPU fault for this MPUs
Well that's not going to help you.
http://www.keil.com/appnotes/files/apnt209.pdf
blog.feabhas.com/.../
You follow the evidence, if it always hard faults, the easiest way to track it down is to examine what was happening at the point of failure, and make deductions from that.
Likely issues with stacks, reading/writing to bad memory addresses. For smaller memories make sure you shrink the target memory space, reduce stack and heap as required.
very nice guides!
Thanks for them.
I tracked the exception as thought in the above debugging guides.
It is an unaligned usage fault
and the disassembled line is
LDR r8, [r1, r8 ,LSL #2]
while: r8 = 0x4E725A6C R1 = 0X412ADC
but this happens while i have SCB->CCR = 0x200 which implies that UNALIGNED_TRP bit is 0.
As I read unaligned usage fault will be caused by Load/Store multiple instructions and any other load/store instruction can cause it only if UNALIGNED_TRP bit is set.
So what's wrong with my LDR instruction here?
I read the r1 and r8 from registers view which is not the value when executing the LDR instruction.
The R1 value causing the exception, which is read regarding MSP address is : 0x412ADC and r8 is not available i think
Further debugging shows that the unaligned usage fault is caused when r8 contains an irrationally big offset, which is acceptable.
Still working on it ...