On 03/17/2016 03:40 AM, spflanze wrote: > This is a firmware project of mine. The IDE is the Ac6 System Workbench. > The target processor is an STM32F373VCT6. > > I find that whenever I have a function that has within it a call to another > function this instruction sequence appears among the first instructions in > the function that does the call. > > sub.w r3, sp, #12224 ; 0x2fc0 > subs r3, #60 ; 0x3c > movs r2, #0 > str r2, [r3, #0] > > This sequence results in a Bus Fault because in the last instruction r3 > points to a location in flash memory instead of a location in RAM as it > should. The details of how that happens is posted in this thread of mine > that I began when I thought this was a FREERTOS problem: > https://sourceforge.net/p/freertos/discussion/382005/thread/da34d0b6/ > > This instruction sequence is not just near the start thread function for > which I posted source code. It is near the start of every start thread > function in the project. If there are no function calls withing the start > thread function the above instructions disappear. > > Why do these functions need to store a value of 0 at a location so far from > the current stack pointer address? What is this instruction sequence > supposed to accomplish? It would have been nice, if you would have included the gcc command line. Do not use -fstack-check. It's the cause of your problems. The compiler obviously assumes that you need at least 12224 bytes of stack (seems to come from gcc/defaults.h, STACK_CHECK_PROTECT). The code tries to touch deep into the stack in order to fault in case of a too small stack (and faulting is what it does, doesn't it? :-) ). If you need stack checking, setup a 32 byte guard band (must by 32-byte aligned) at the bottom of your stack, protect it with the mpu of the cortex-m4 and switch the region register on every context switch. That way you need only one MPU region. Setup another region register to cover the bottom of your interrupt stack. And now that you have started using the mpu make use of the remaining regions (you have 8). e.g.: Region 0: Disallow any access to the first gigabyte (catches NULL-pointer access), Region 1/2: Allow access only to the ram you actually have (no access to mirrored locations) Region 3: Disallow writes to your flash, allow read access only to the amount of flash you actually have (no access to mirrored locations) Region 4: Disallow write access to your vector table. That way your fault handlers can't get compromised. Region 5: Interrupt stack guard band Region 6: Task stack guard band Region 7: Spare That's not perfect, but it will catch most stack overflows and lots of illegal pointer usages. regards, Matthias -- Matthias Pfaller Software Entwicklung marco Systemanalyse und Entwicklung GmbH Tel +49 8131 5161 41 Hans-Böckler-Str. 2, D 85221 Dachau Fax +49 8131 5161 66 http://www.marco.de/ Email leo@xxxxxxxx Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München