How can I distinguish the reason for hardfault?

RE: How can I distinguish the reason for hardfault?

RK — Thu, 23 Jul 2015 08:53:44 GMT

ARMs documentation is awesome, but it's very, very, very, VERY long. All this stuff is in the ARM V6M Reference, which is 600 pages long, the V7 one is 1100 pages long. There's a couple of books, The Definitive Guide to The ARM Cortex M0 (and M3, M4 etc) which are pretty good if you want to get a good understanding, then you can dip into the manual later for the details. Mostly you don't need to know it however.

ARM also has their infocenter which has the same stuff, but indexed and with a few pretty diagrams, probably as part of a similar but different target user manual (the generic user guide). The stack picture is here infocenter.arm.com/.../index.jsp, the PSP register details are elsewhere, you can piece it slowly together.

RE: How can I distinguish the reason for hardfault?

MANGO — Thu, 23 Jul 2015 08:39:32 GMT

Wow, it sure is painful...

I should have read both your answer and the Cortex M0 manuscript from ARM more carefully,

but where did you get these infos?

Like The word after the PC, that's the PSP

, R1 is also stacked by the interrupt routine at SP,

and an unaligned load?

I lack of many basic knowledge of Cortex M0 architecture.

So I was curious that where did you received all these infos.

Also, about the unaligned load, you mean the code loaded from R0 + 0x04 was not even, right?

Always appreciate your help and nice guess.

RE: How can I distinguish the reason for hardfault?

RK — Thu, 23 Jul 2015 08:32:30 GMT

Well I tried :).

Ok you can see why that crashes, r0 is 0x00000001 (that's also stacked by the interrupt routine at 0x200032D0) and 0x00000001 + 4 == 0x00000005 and that's an unaligned load. On the nRF52 that would have given you a better fault AND a nice error code, except it wouldn't have as that allows unaligned loads unless you turn that off.

So now you just have to work out why the head timer isn't TIMER_NULL but the timer table contains totally bogus addresses like 0x00000001. That shouldn't be too hard.

And now you know how to track 2-level deep stacked interrupts. Painful isn't it.

RE: How can I distinguish the reason for hardfault?

Susheel Nuguru — Thu, 23 Jul 2015 06:46:47 GMT

edited.. thanks

RE: How can I distinguish the reason for hardfault?

RK — Thu, 23 Jul 2015 06:24:40 GMT

[ 0x200032D0 + 0x18 ] .. I think

RE: How can I distinguish the reason for hardfault?

RK — Thu, 23 Jul 2015 06:23:11 GMT

Doing it as an answer even though it's not because the comments are restricted to about 2 lines!

01 00 00 00 in little endian is neither of the above, it's 0x00000001. Anyway that's not where you came from.

SP is 0x200032D0, so the return PC at exception time is stacked at that +0x18 = 0x200032E8 which has contents 0x00019b5a.

The link register is 0xFFFFFFF1 which means return to handler, which means you hardfaulted inside an interrupt handler .. but which one.

The word after the PC is at 0x200032EC and is 0x01000021, that's the PSP. Bit 24 is set telling you you came from Thumb mode, well we knew that. The lower 5 bits are 0x21 which is 33 which is the number of the interrupt being processed. Interrupts start at '1' for the reset handler, the first user interrupt is 16 so this is user interrupt ( 33 - 16 ) = 17. Interrupt 17 is RTC1.

So it looks like there was something which caused a hardfault inside some code called by the RTC1 interrupt handler (ie I guess a timer) the instruction causing the fault was at 0x00019b5a.

I'll hazard a wild guess that instruction turns out to be SVC .. see if I'm right.

RE: How can I distinguish the reason for hardfault?

Susheel Nuguru — Wed, 22 Jul 2015 09:46:38 GMT

No, you have to look what inside the memory location of where SP is pointing to. That is check the memory contents of 0X200032D0, to the contents add 0X18 (add to the contents of memory location pointed by SP) You just added 0X200032D0+0X18 <-- This is wrong you must do [0X200032D0 + 0X18], then you will get the instruction address that caused the hardfault. you can check where this instruction lies my checking the .map file generated in _build folder

RE: How can I distinguish the reason for hardfault?

MANGO — Wed, 22 Jul 2015 09:05:40 GMT

Using the picture where it shows the registers,

then at Memory 0x20032E8, there's the instruction that caused the exception?

I haven't tried it but won't there be similar instructions?

For instance, if the instruction was "MOV" at 0x20032E8,

how could I found that instruction's location?

RE: How can I distinguish the reason for hardfault?

Susheel Nuguru — Wed, 22 Jul 2015 07:19:18 GMT

One way to do it is like this.

Check this infocenter.arm.com/.../index.jsp

You can see that on Cortex-M0, on Exception entry (like Hardfault) the address of instruction that caused the exception is pushed onto stack at SP+0X18. You can check the symbol table, .map file, and find out which function caused it.