Hi,

I've experienced the same problem with the compiler, and have reduced a project to the barest minimum required to replicate the issue. This project simply enables LED1 on the STM32 EVAL board, and using the Systick Interrupt running at 5Hz blinks the LED.

When compiled with "Pack Structure Members = YES" the code ends up the the HardFault Handler.
When compiled with "Pack Structure Members = NO" the code operates properly and blinks LED1 at 2.5Hz.

NOTE: Always perform a CLEAN before a BUILD, otherwise the project files aren't recompiled/updated correctly.

Version Information:
Ride7 - 7.30.10.0159
Ride7 Patch - 7.30.10.0169
RKit-ARM for Ride7 - 1.26.10.0130

Hmmm ... how do I attach a file in this forum???

I will send the example project files to instead.

Regards,
Robert.

Hi Robert,

Thanks for your detailed report. We have been able to reproduce this behavior in our Labs.
It looks like we have 2 problems here:

1. For some reason, when using packed structures GCC generates a very specific code on the following line:

   FLASH->ACR |= FLASH_ACR_PRFTBE; /* Enable Prefetch Buffer */

   The generated code will perform four 8-bit load/or/store patterns, which is poorly optimized.

   [/*]
   

2. When writing a byte (using the "ldrb" opcode) to address 0x40022000 (address of FLASH->ACR), the STM32 goes direct to HardFault_Handler() [/*]
   

We will check whether point 1) should be corrected.
Concerning point 2), we need some information from ST to qualify the problem further (it may be a standard behavior).

As a workaround, I suggest that you explicitly pack the structures that you NEED to pack, and leave all other structures unpacked.

The "#pragma pack" GCC directives can be used for such, as in the following example:

I hope this helps,

volatile int titi;

#pragma pack(push,1)
struct mys 
{
    char c;
    long l;
} toto;     // This structure is held in 5 bytes
#pragma pack(pop)

struct mys2
{
    char c;
    long l;
} toto2;    // This structure requires 8 bytes (it is NOT packed)

titi = sizeof (toto);    // titi equals 5
titi = sizeof (toto2);   // titi equals 8

Hi Bruno,

I'm pleased that you were able to replicate it easily, and thank you for the quick reply.

For my needs I had already done the #pragma workaround (first thing I tried actually), and have therefore only applied it to my structures (as per your example) and not globally to the project.

It also appears that there is a large amount of compiler inefficiency when packing structures = YES (locally and globally), as the code size goes up dramatically - so it is quite possibly a bug in the compiler or potentially in the optimiser.

Point 2) is something I would not have expected. It might just be a combination of opcode/address which is unexpected for access to that register. Errata: 'Just don't do it that way!' ;-)

Thanks again - please update this thread again when the issues have been resolved/addressed.

Cheers,
Robert.

This could very well be the case as load/store operations on a packed struct might generate bytewise access ( lots of shifts and masks ) instructions if it's not aligned to what the ARM core wants.

With regards to point 2 Bruno is mentioning:
In my search for the problem in my own topic ( which has also to do with struct member alignment ) i came across some info regarding the Cortex-M3 core having some errata on LDRD operations, maybe thats causing your problem?
Is also seems that arm-gcc has some workaround for that ( -mfix-cortex-m3-ldrd ).

[edit]
According to this page : http://gcc.gnu.org/gcc-4.4/changes.html the flag i mention is in GCC 4.4.something, ergo the version you are using probably doesnt support it.

[edit2]
Even more info:
The Cortex M3 requires that access to memory be aligned. In your OP, when instructing the compiler to pack the struct the access to the u16 field might or might not be aligned (depends on the base address of the struct ) because there is a one byte field in front of it.
( See also http://lwn.net/Articles/259732/ for more info about aligned/unaligned access )

I realise this, but the scale of the codesize change is far larger than I would think it should be - on the order of 50% larger for the trivial example I had provided to Raisonance.

The structs are (generally) aligned on short or long boundaries, which shouldn't require byte access and shifting. The compiler appears to pad out the compiled map (for some reason), and inserts dead space as well. I don't have the project handy at the moment, but might check into this later.

Very interesting! Thanks for the research & links. I wonder if the best answer is to wait for Raisonance to upgrade GCC to 4.4? :-)

Anyways ... still trying to solve another odd MCU lockup bug when using SPI2 and DMA ... (Brief Summary:) After about 6 to 20 hours under full/continuous load, I manage to get the MCU to entirely lock up. No bus fault, no obvious failure, no interrupts happening - basically nothing. Only PWM and (apparently) timers are still running ... but no interrupts are being called. This is very, odd. Nothing in the Errata I can find ... but I'm trying to solve this one now ...

Regarding the other bug: Could it be that for some reason you are not clearing some interrupt and it is only processing higher priority interrupts and for the rest handling your 'not cleared interrupt' very fast? That situation could seem like the CPU is locking up, but not for some specific interrupts.

Hi all,

The next RKit-ARM release will be based on GCC 4.4, with lots of other goodies.
We are waiting for a marketing annoucment from ST before releasing it. Hold your breath until then...

Regards,