Sam4s program hardfaults in higher flash memory

Discussion around product based on ARM Cortex M4 core.

Moderators: nferre, ncollot

tallman
Posts: 42
Joined: Wed Mar 20, 2013 4:09 pm

Sam4s program hardfaults in higher flash memory

Fri Jul 25, 2014 4:22 pm

Anyone ever have something run fine when running in regular default flash area (0x400000-0x500000) for my Sam4s, but when I tell it to run .text=0x408000) with even a simplified bootloader that just jumps to the reset handler, the software startsup and works for a bit, but I hit an area of code and get a hardfault.  It all works fine in default area (and has been for a many months of development).  Just adding a bootloader now, and I'm getting this hardfault.

I've installed the assembly to see the registers at the hardfault, but I'm stuck as the program counter is giving me some crazy out of range location, and I'm not sure what else is useful in the registers.  I've attached just in case, but I'm lost as to how to find this problem. 
Any advice for further research would be appreciated.
Brent
Attachments
hardfaultbs.jpg
hardfaultbs.jpg (751.8 KiB) Viewed 2904 times
jharley
Posts: 238
Joined: Thu Dec 06, 2012 6:40 am

Re: Sam4s program hardfaults in higher flash memory

Sat Jul 26, 2014 4:33 pm

According to the HardFault Status Register this appears to be a "Bus Fault"

What is the value of the "Bus Fault Status Register" (0xE000ED29) ?

Some links ...
http://infocenter.arm.com/help/index.js ... FDJCA.html

http://community.arm.com/servlet/JiveSe ... %20ARM.pdf
tallman
Posts: 42
Joined: Wed Mar 20, 2013 4:09 pm

Re: Sam4s program hardfaults in higher flash memory

Sun Jul 27, 2014 1:12 am

Thank you jharley for giving me some clues for further research.  This is very valuable.

 I looked in 0xE000ED29 which according to docs holds the BFSR.  It has
0xE000ED29 01 00 00 00 00 00 40 00 00 00

The docs say it's storying half word access, so I'm thinking this is PRECISERR (bit 9 on).  If that's true (which it would help if you could confirm I'm understanding this), then it says PC value stacked for the exception return points to the instruction that caused the fault and BFAR holds the faulting address.  PC holds 0x16171716  so I don't know what to do with that.  And BFAR holds 0xE000EDF8 which has 00 00 00 00.  I'm not sure what to do with that or if I have any of this correct.

I'll keep looking around, but does this lead to anything?
Thanks.
Brent
Attachments
sysmem.jpg
sysmem.jpg (261.49 KiB) Viewed 2863 times
jharley
Posts: 238
Joined: Thu Dec 06, 2012 6:40 am

Re: Sam4s program hardfaults in higher flash memory

Sun Jul 27, 2014 3:45 am

Hi Brent,

From your first screen cap:
CSFR 0x100 : IBUSERR
stacked_pc : 0x03030202
stacked_lr : 0x0040DAE1

The bus error is usually caused by accessing an invalid memory location.

The PC is out of range so not much help there to track down the issue. So, I would try looking up the LR address in a program dump.

To do this disassemble your .elf file and scan thru it to see were you came from to get into the hardfault handler. Once you see where you came from look for any possible bad or uninitialized pointers, or is there any code that is unbounded in its memory access (e.g. trying to access a memory location of an array that is out of range)

To disassemble, if you are using gcc, use objdump.exe

If you are using Atmel Studio look under the install directory for this... on my system it is located in the following directory...

C:\Program Files (x86)\Atmel\Atmel Toolchain\ARM GCC\Native\4.8.1429\arm-gnu-toolchain\bin

eg. if your elf file name is foo.elf

Code: Select all

arm-none-eabi-objdump.exe -S foo.elf > foo.dump
Then you can open the foo.dump file in a text editor and scan for the address reported by the stacked LR.

good luck... these hardfaults are sometimes hard to track down.
tallman
Posts: 42
Joined: Wed Mar 20, 2013 4:09 pm

Re: Sam4s program hardfaults in higher flash memory

Sun Jul 27, 2014 5:28 am

Thanks for the response and information.  I am happy to say I have found the problem but I don't know how to fix it.

When I moved the memory startpoint using the .text, it seems the stack is pointing now to area that is also covered with one of my buffer arrays.  So I have a large array that gets populated, and it so happens the stack is right in the middle of the array location, so it wipes out the stack (along with later a pop to pull registers and PC)

Where does this get set?  I assumed it was automatic.  When I look at the map, it lists

Code: Select all

.stack          0x2001d7c0     0x3000 load address 0x00435338
                0x2001d7c0                . = ALIGN (0x8)
                0x2001d7c0                _sstack = .
                0x200207c0                . = (. + STACK_SIZE)
 *fill*         0x2001d7c0     0x3000 
                0x200207c0                . = ALIGN (0x8)
                0x200207c0                _estack = .
                0x200207c0                . = ALIGN (0x4)
                0x200207c0                _end = .
 
 I'm not sure thats the only stack, because when I start the program, the stack location is listed in the debugger as 0x2000B4C8.  In my map, my arrays cross this area.

Code: Select all

               0x20002230                FramePartSize
                0x20002234                CaptureBuffer_2
                0x2000b834                CaptureBuffer_1
 
I'm really close I know it.  Thanks for your expertise.  I learn so much more in these efforts (but they are frustrating).

Brent
tallman
Posts: 42
Joined: Wed Mar 20, 2013 4:09 pm

Re: Sam4s program hardfaults in higher flash memory

Sun Jul 27, 2014 10:28 pm

I have found an issue with my stack, that I'm working on so I'll say this problem is past hardfaults now.  I have a bootloader, then when I'm jumping to my main program from the bootloader, I don't think the stack is getting set correctly, so I'll post a different question if I can't resolve this.

Thanks Jharley for your help!  It was extremely valuable.
Brent
ylanz
Posts: 18
Joined: Mon May 05, 2014 12:57 pm

Re: Sam4s program hardfaults in higher flash memory

Thu Sep 18, 2014 9:08 am

Hi tallman, 

Can you tell me how put watch variable in the code as you do ? 
I don't find anything and it seems to be very useful  :?

Regards
tallman
Posts: 42
Joined: Wed Mar 20, 2013 4:09 pm

Re: Sam4s program hardfaults in higher flash memory

Thu Sep 18, 2014 4:08 pm

If you are using Atmel Studio then you just mouse over the variable.  You can pin this to the screen, and also right click.  Make sure in your project settings/toolchain  you have debugging set to -g2 or -g3. 




Hope that helps.
Regards
ylanz
Posts: 18
Joined: Mon May 05, 2014 12:57 pm

Re: Sam4s program hardfaults in higher flash memory

Thu Sep 18, 2014 9:59 pm

Thank you very much, it will be very useful  :D

Regards

Return to “SAM4 Cortex-M4 MCU”

Who is online

Users browsing this forum: No registered users and 1 guest