IACCVIOL

[guidesanti]

Posted on May 25, 2012 at 18:50

Hello,

I am working with a STM32100 RBT6 microcontroller. I was working on a firmware and as the souce code grows up a I had the software starts reach the hard falt handler. I loocked for the CFSR register and the IACCVIOL was set. The strange thing is that, if I comment some code the software starts to work as expected and when I add more code the software starts to generate the instruiction access violation falt. The firmware is about 32Kb long and the microcontroller has 128Kb of flash, so it suffices. Do anyone have some idea about this problem? Thank you.

[frankmeyer9]

Posted on May 25, 2012 at 20:03

I would try to increase the stack size. Those Heisenberg-bugs are often related to overflows.

Some toolchain are more generous with their default size, some are not

[Tesla DeLorean]

Posted on May 25, 2012 at 20:07

The solution is to examine the stacked state, and figure out what code is faulting. ie extract the faulting PC and disassemble the code around it. You can do this manually, or use a fault handler that decodes it. There isn't much reason to guess why it's occurring.

It will hard fault if you try to execute 32-bit ARM code. So check the branch and calling code.

[Tesla DeLorean]

Posted on May 25, 2012 at 20:14

I would try to increase the stack size. Those Heisenberg-bugs are often related to overflows. Some toolchain are more generous with their default size, some are not

Most of the default projects, at least for Keil, are 1024, this can be inadequate for things like scanf/printf type functions. Look for a ''POP {PC}'' or ''BX LR'' as a faulting instruction.

[frankmeyer9]

Posted on May 25, 2012 at 20:18

I mostly use Crossworks, which has a default stack size of 128 bytes.

That's a little stinted.. As mentioned, other toolchains are more generous.

[Tesla DeLorean]

Posted on May 25, 2012 at 20:29

I mostly use Crossworks, which has a default stack size of 128 bytes.

That's a little stinted..

As mentioned, other toolchains are more generous. Yeah, 128 is pretty measly, 1024 isn't terribly generous either. Some place it differently, GCC often sticks it at the top-of-ram, whereas Keil, for example, sticks at the end of the static initializations. Much fun and hilarity occurs when the stack ploughs into them. Being large enough is something PC developers often overlook with very large local/automatic allocations, and little consideration of call depth.

[guidesanti]

Posted on May 25, 2012 at 21:36

I would like to ask you for apologize.

It was a big mistake of mine. My code erases the last page of the flash after every new software programed. But this page was the 31, as the source grows I moved this page to 127 on the linker file, but the code has a define with the page number 31 and I forget to changed. So my code was  erasing part of itself, and as my code runs some functions using function pointers it try to jump tp 0xFFFFFFFF and consequently generating a hard falt exception. Sorry for that again. Guilherme

[frankmeyer9]

Posted on May 26, 2012 at 11:14

That is a common issue, too.

It is hard to adhere to the 'single source' principle, if the references to this definitions are coming from different types of sources - say, *.c/*.h file and linker scripts. I suggest a pre-build step, were these sources in question are automatically generated or modified from the single configuration source. For larger or commercial projects, it's really worth the effort. Sooner or later you loose track of all the interdependencies. If you search for an example, look at unix/linux source packages, what happens if you run ''./configure''.