Hard Fault on first SRAM access

[robertroy9]

Posted on August 23, 2012 at 04:51

Hello,

STM32L152, Rowley CrossStudio 2.3, STM32L152DEMO pcb, Using CrossConnect debugger within CrossStudio.I have seen this problem before, did not record/understand last time fixed.What will cause a hard fault on first SRAM access in program (after startup_.s). I have a bunch of static structure global declarations before main, once in main execution hard faults at first SRAM access (usually is a push (R7, lr) ) and those values look reasonable.Getting VCATCH, IMPRECISERR set, and drops to HardFault (CMSIS version). If I manually set CSB_SHCRS->BUSFAULTENA and rerun it will drop into bus fault handler.The modified handler returns this:[Hard fault handler - all numbers in hex]R0 = 20001940R1 = 0R2 = 0R3 = 0R12 = 1fffe944LR [R14] = 20001950  subroutine call return addressPC [R15] = 8000379  program counterPSR = 80006a0BFAR = e000ed38CFSR = 400HFSR = 40000000DFSR = 8AFSR = 0SCB_SHCSR = 0Tried making this the first thing in

uint32t *ACTLR = (uint32_t *)0xE000E008;

// *ACTLR |= 2; never executed this 

[Hard fault handler - all numbers in hex]R0 = 20001940R1 = 0R2 = 0R3 = 0R12 = e008LR [R14] = 20001950  subroutine call return addressPC [R15] = 8000177  program counterPSR = 8000378BFAR = e000ed38CFSR = 400HFSR = 40000000DFSR = 8AFSR = 0SCB_SHCSR = 0help or thoughtful guidance appreciated. #stm32-hardfault-impreciserr

[robertroy9]

Posted on August 23, 2012 at 21:22

Clive,

 If I look at GNU I see something I never wanted to know about but under the circumstances...

http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gccint/Function-Entry.html

So you meant the generating prologue code to save <stuff> used by the epilogue code on exit of main? Since this is an embedded app, and exit means reset there is nothing to save. I wonder how I could be mucking that up?And many thanks for your insight and help.Rob

[Tesla DeLorean]

Posted on August 23, 2012 at 21:40

Yes, was thinking ''prologue'', darn dyslexia... Prologue as it enters, Epilogue as it leaves.

You might have allocated something deeper into the routine, or compound statement. The compiler might fold that up, and do one large allocation upfront to account for the maximum required. int main(void) {   char foo[12 * 1024]; // allocates on stack } int main(void) {   static char foo[12 * 1024]; // allocates in RAM } int main(void) {   static const char foo[12 * 1024]; // allocates in ROM, probably, think large table for CRC or Font, or something. } Not sure you need to fully understand the assembler side of stuff, but it helps if you can decipher enough in the disassembly window to see below the C statements. The startup stuff is normally hidden by the ''Run to main()'' options in the debugger. Stack based local memory is used a lot in embedded because malloc()/free() can be troublesome, running out of memory, or fragmenting. With stacked variables need to watch how deep you descend into subroutines, and that content will be random junk, unless explicitly cleared/initialized.

[robertroy9]

Posted on August 23, 2012 at 23:10

Thanks, I would like to avoid stack allocation of arrays and structures I am pretty sure.

Back in the day, we told the compiler where to place the variables and masked it off. That is what I want to do, and use pointers to reference them. Seems foolhardy for the compiler to put all my variables in the stack.....Rob

[Tesla DeLorean]

Posted on August 24, 2012 at 04:24

Seems foolhardy for the compiler to put all my variables in the stack.

It doesn't, just the ones you define with limited scope. I don't see enough of your code to point out why.