Hard fault at misaligned memcpy memset

[ingwmeier]

Posted on April 15, 2013 at 16:11

Already posted this on Keil Website, it was tested with STM32F100, therefore:

we made some simple tests with STM32F100 Value Line Eval Board:

//------------------------------------------------------------------------------

// Variables static unsigned char sDstBuf[1024]; // 1KiB static unsigned char sSrcBuf[sizeof(sDstBuf)];

printf(''Copying words from misaligned src to aligned dst buffer... '');

memset(sDstBuf, 0xcd, sizeof(sDstBuf));

with optimize Level 3, optimize for time this takes

120usec

with optimize Level 0

155usec

almost the same if memcpy is used:

memcpy(sDstBuf, (const void *)0xcd, sizeof(sDstBuf));

It runs into hard fault, if optimize Level >=1 and optimise for time is not set.

I think this is a compiler error..

We ran into this before with MDK 4.60, now we use 4.70A

Werner

#cross-post #memcpy

[ingwmeier]

Posted on April 16, 2013 at 14:06

Thanks all, I gave the details to Keil, we actually wanted to check with this example, what happens when there is unaligned access.

I had an issue with memcpy, where it copied stored information either from ram or flash to a structure a while ago, from one source it was ok but from the other it ran into the same Hardfault. I can't examine this anymore. This was the reason why I jumped to a wrong conclusion in the first place. Again thank you all. I had difficulties with accessing this Forum, therefore the crosspost on the Keil website was answered before. Werner

[frankmeyer9]

Posted on April 16, 2013 at 15:12

That might be true for the C standard, but would not be expected for an implementation.

... null pointer, JW], the result is implementation-defined, might not be correctly aligned, ... And the Keil compiler is such an implementation, which needs to define its alignment requirements. And if the compiler emitted code with with word-alignment requirements for the clib memcpy() function, I would consider this a bug. But as it turned out, that was a misunderstanding on my side - the offending code was not in memcpy().

[waclawek.jan]

Posted on April 16, 2013 at 23:13

[strictly academic mode]

> And if the compiler emitted code with with word-alignment requirements for the clib memcpy() function, I would consider this a bug. The ''harm'' is done at the moment when the integer is cast (thus converted) to pointer, although  the fault is thrown later - when the pointer is accessed. Note, that the incorrect pointer remains to be incorrect regardless of its future casts, even to void*. The compiler is free to choose such internal representation of the pointers which preserves the type across conversions through void*, for example. Thus, if you use an ''incorrectly'' created pointer as a parameter in call to memcpy(), it's converted implicitly to void* because of the parameter's prototype, but memcpy() still may throw an error in runtime. It's enought that this is mentioned in the compiler's documentation (as per requirement for ''implementation-defined''). [/strictly academic mode] Such behaviour would be highly unusual, indeed. The possibility of fault when dereferencing a pointer to word created through cast from an integer which is not multiple of 4, should still be mentioned in Keil's documentation as per the ''implementation defined''. Anybody to check (I don't Keil)? JW

[ingwmeier]

Posted on April 19, 2013 at 08:31

Just got answer from Keil:

This isn't actually a compiler fault, as unless the integer pointer is declared

as packed, it must be suitably aligned. It just happens to be fortuitous that at -O0 it generates safe code. I was not aware of this. I also can't remember seeing the key word packed in any of the Cortex M3 Software Examples from ST / TI (Luminary) or NXP..

[waclawek.jan]

Posted on April 19, 2013 at 09:38

This isn't actually a compiler fault, as unless the integer pointer is declared

as packed, it must be suitably aligned. Is this detailed somewhere in Keil's documentation? JW

[ingwmeier]

Posted on April 19, 2013 at 13:37

Support from Keil gave me this link:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472c/CJAJDDHB.html Werner

[acelec]

Posted on April 19, 2013 at 18:57

Hi

Optimisation at Keil is mostly doing kind of  LDR / STR sequence instead of memcpy .... it is faster ! This link is interesting as well: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html