Bug in Dave. Linker is producing Code with a Hard fault

[User11996]

Hi.

There is a bug in Dave (in combination with the toolchain).

The Linker produces code, that stop working after an indefinite time with a HARD-FAULT: unaligned access
in case if i try to read or write a normal declared variable in the RAM of a XMC4400.

I don't access the variable with a pointer...
I have no external databus..


Example:

uint32_t lBufferArray[100];

uint32_t Myfunction( uint8_t  cIndex)
{
    if ( cIndex < 100 )
    {
       return  lBufferArray[cIndex];
    }
    else
    {
      return -1;
    }
}

Depending on the memory usage, the error occurs for example,
if i call the Function for example:

uint32_t lDummy;
lDummy = Myfunction( 5 ); // Hard fault, at a read access of a ram variable at index 5. (0..4 is working, 6..99 is working)

It is a normal and valid code, isn't it?

How can I prevent, that the linker produces code with a Hard-fault error, if a execute valid code?
How can i be shure, the my code is running without a Hard fault, if a write valid code?

The Linker is placing the lBufferArray in SRAM @ Adress 0x1FFFFxxx to 0x20000xxx.
So the Infineon microcontroller is generating the hard fault at any read or write access.

If a add the next variable, the code is working without hard fault
If a add the next variable, the code is producing a hard fault
If a add the next variable, the code is working without hard fault
If a add the next variable, the code is producing a hard fault

But it is normal, legal, valid c source code......

[jferreira]

Hi,

The SRAM in the XMC4400 is divided in blocks: PSRAM (0x1fffc000-0x1fffffff), DSRAM1(0x20000000-0x20007FFF) and DSRAM2 (0x20008000-0x2000FFFF).
Have a look to this entry in the reference manual of the Cortex-M4 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/ch03s04s02.html
Most probably is an alignment issue (it would be helpful to look into the map file) which leads to an address wrapping to 0x0 at the boarder between the PSRAM and DSRAM1 causing a bus fault.

Please try to change the variable declaration as follows:
__attribute__((aligned(4))) uint32_t lBufferArray[100];

By this you ensure that no split access is done while accessing the 32bit elements of the array and therefore the wrapping at the border as described in the link above will not occur.

Regards,
Jesus

[User11996]

Hi Jesus.

Yes, you have perfect explained the technical background from the problem of the hard fault. That's the reason..


But how can i handle this problem in a big project. The problem occurs, if i use more RAM than the PSRAM .

In my big project i have hundrets of variables, structures, arrays,....
So the problem is today on array#7 , tomorrow on structure #27, in a week in variable #1357. My memory layout is changed every day..

Is there no global solution available?

[jferreira]

Hi,

You can use -mno-unaligned-access compiler option to avoid unalign access.
In addition you can look to the map file to see which variable cross the border and for the appropiate allignment.

Regards,
Jesus