Problem with uint64_t and EXTI Callback function

[herbert]

Posted on May 11, 2016 at 15:43

Hello,

I use the HAL EXTI callback function on an STM32F411 and have made the following strange experience:

When changing data types from float to uint64_t for Efficiency in another callback function (actually from DMA), my EXTI interrupts suddenly stop working. The debugger shows that the EXTI int is pending but the callback function gets not called any more.

Does anybody here have any ideas what is going on here or probably have similar experiences?

regards

Herbert

[Radosław]

Posted on May 11, 2016 at 15:52

Stack pointer You set aligned to 8?

[Tesla DeLorean]

Posted on May 11, 2016 at 17:24

Less inclined to think the stack alignment matters, 4-byte would suffice, now byte level misalignments in structures, that's another matter.

Instrument the actual IRQ Handler, not your call-backs, and determine where the processor is when it fails, ie stuck in a Hard Fault Handler, etc.

[Radosław]

Posted on May 11, 2016 at 19:47

>>4-byte would suffice,

Not true

[Tesla DeLorean]

Posted on May 11, 2016 at 20:19

>>4-byte would suffice,

 

 

Not true

The Cortex-M4 is demonstrably capable of doing LDRD loads on 32-bit aligned addresses, do you have some specific test case where 8-byte alignment is required?

[Radosław]

Posted on May 11, 2016 at 20:27

google STK_ALIGN

and etc.

ABI defines that stack must be aligned to 8 when interrupts call external function (64bit parameter)

From Keil startup

Stack_Size      EQU     0x00000400

                AREA    STACK, NOINIT, READWRITE, ALIGN=3

Stack_Mem       SPACE   Stack_Size

__initial_sp

Defines Stack pointer to be aligned to 8 bytes.

Any

doubts?

I from beginning use 8-bytes aligned stach and i never havce problem with that.  maybe i will try to check it.

[Tesla DeLorean]

Posted on May 11, 2016 at 21:19

Ok, but you're proffering that the lack of 8-byte stack alignment is some causal reason for it to fault on the system the OP described, and I'm saying it's not.

I understand what stack alignment is, I don't need to Google it, and you know that too. For you to prove that I'm wrong in this instance, you'd need to provide a specific test case on the M4 that demonstrates that, not postulate and point at Google, or wave the ABI around.

The ABI tries to define a concept/method that will work on all platforms, and is thus the most restrictive and limiting in order to achieve it's goals.

The speed limit of some of the road around here is 55MPH, but they don't stop functioning a significantly higher rates, although the cops may wave the ''rules'' around, and talk about safety.

[Radosław]

Posted on May 11, 2016 at 21:42

In free time maybe i will try to test it, But for now. 

8-byte stack alignemt is neccasary when assembly calls C function,

I just google littlebit and i found few cases with problem with stack not aligned to 8.

Speccialy on M3 when STK_ALIGN=0;

So tell me why in keil You can set initial stack pointer not aligned to 8?

[Tesla DeLorean]

Posted on May 11, 2016 at 22:16

Because it embodies the ideals of the ABI, in peace and love between multiple architectures on which the objects might interact. Rules of engagement if you will.

Byte level misalignments can cause failure, again the LDRD or STRD will demonstrate this both on a stack frame, and if you access unaligned double's or uint64_t's in a structure built with pack(1). ST's stupid SP=0x2001FFFF being a prime example in the GNU linker script. 

The challenge on the floor is to come up with some example code sequence where the unforeseen side-effect of a 4-byte aligned stack/pointer alignment causes the processor to fault, and the 8-byte aligned stack/pointer would not. Ideally this code would be naturally emitted by a compiler, but a neat assembler example would also suffice.

[herbert]

Posted on May 12, 2016 at 11:37

Folks,

thanks for the hints but I have rechecked with my Keil Startup file and it definitely says ALIGN=3, so this should not be an issue any more.

Yet my problem remains that I can safely use uint64_t in global vars but as soon as I try using them as local vars in functions my EXTI callback fails.

regards

Herbert

[knielsen]

Posted on May 12, 2016 at 16:44

You probably have a bug in your code that causes random failures. For example stack overrun or buffer overrun or other similar issues. And the uint64_t usage causes the compiler to generate sufficiently different code that it makes the bug trigger a failure.