Load Alignment Exception with Arm Compiler 6.13

Thank you for looking in to this Ronan.  What I have found out with further investigation is that when we hit this scenario, the MMU is disabled.  In order for unaligned loads to be supported, the MMU needs to be enabled and the memory region defined as "Normal".  My guess is that your test has the MMU enabled.

Since this is happening in 3rd party code that I do not want to modify if at all possible, I was hoping that there would be some compiler option to force strict alignment for the target CPU.  Arm Compiler 6.12 seems works, but when I add --no_unassigned_access to the linker, it still complains that the objects are not aligned properly.

Note - this so only happens with optimization turned off.  If enable optimization, the issue goes away.  I could just be getting lucky vs. something to rely on.  The ROM is embedded into the HW, so not something we can change.  

I guess my questions is if it is possible for the compiler to generate code that does strict aligned access via command option, or do I need to update the code itself to use attributes?  If there is no command option, I may have to enable the MMU in reset vector before jumping to the entry point.  We were hoping to not have to do this until we start the next stage bootloader, which is upgrade-able. 

Thank you for looking in to this Ronan.  What I have found out with further investigation is that when we hit this scenario, the MMU is disabled.  In order for unaligned loads to be supported, the MMU needs to be enabled and the memory region defined as "Normal".  My guess is that your test has the MMU enabled.

Since this is happening in 3rd party code that I do not want to modify if at all possible, I was hoping that there would be some compiler option to force strict alignment for the target CPU.  Arm Compiler 6.12 seems works, but when I add --no_unassigned_access to the linker, it still complains that the objects are not aligned properly.

Note - this so only happens with optimization turned off.  If enable optimization, the issue goes away.  I could just be getting lucky vs. something to rely on.  The ROM is embedded into the HW, so not something we can change.  

I guess my questions is if it is possible for the compiler to generate code that does strict aligned access via command option, or do I need to update the code itself to use attributes?  If there is no command option, I may have to enable the MMU in reset vector before jumping to the entry point.  We were hoping to not have to do this until we start the next stage bootloader, which is upgrade-able. 

Hi again Dave,

I made a more complex example, but still cannot replicate your issue. The -mno-unaligned-access option protects me :(
Some potential workarounds are listed below, they will all require some (minor) changes to source...

1) Use __attribute__((aligned(x))) in the data definition:

volatile char __attribute__((aligned(4))) hello[]   = "Hello World";

2) Use __attribute__((packed)) when referencing data

extern __attribute__((packed)) char hello[];

3) Separate the data into it's own ELF section, and place it in its own region with scatterloading, with something like:

#pragma clang section data = "Howdy"
volatile char hello[]   = "Hello World";

; scatter file
... 
    DATA1 +0 ALIGN 1024
    {
    	main.o (Howdy)
    }
...

If you would like Arm to investigate more formally, please raise a support case via the link above.

Thanks again Ronan.  Enabling the MMU before we initialize the Trustzone CC712 library did fix the issue and allow unassigned loads of memory addresses not on a 64-bit boundary.    When you tried to reproduce the problem, did you have the MMU disabled?  It is pretty easy to reproduce.

Reading the description of -mno-unaligned-access is a bit confusing.  It doesn't necessarily force strict alignment, but pulls in standard libraries that will do byte reads.  The problem I have is in the 3rd party ARM CC712Tee libraries.  It also seems to only fail using ARM Compiler 6.13.  when I build it using 6.12, I don't get these problems using the same compiler options.

I will put in a support request to verify that the cc712tee and tee-sbrom libraries must be run with MMU enabled.  our own code is properly aligned (using attributes) so it can run without the MMU enabled.