EK-TM4C1294XL: STR.w leads to unaligned memory access

PirateLeChuck

Intellectual 380 points

Part Number: EK-TM4C1294XL

Hi,

in my program for a TM4C1294XL there is an instruction

0xF8420021: str.w r0, [r2, r1, lsl #2]
with
r0 = 0x00000001
r1 = 0x00000000
r2 = 0x20012AD1

This instruction is assembled from the C line

grantedQoSs[(*count)++] = readChar(&curdata);

and probably forms the store process of the array element. However executing this instruction immediately causes a Hardfault The fault type is unaligned memory access, which I can see because UFSR = 0x0100.

Now my question is what exactly does the instruction do? Does it calculate r2+r1 and shift the result left by 2 bits? Then in my opinion an unaligned memory access would not occure.

Best regards

over 7 years ago

0 PirateLeChuck over 7 years ago

Intellectual 380 points

Debugging the C code I found out that a Problem could be that grantedQoSs is stored at address 0x20012AD1. Is it even valid to store a variable at an unaligned address?

0 Bob Crosby over 7 years ago

TI__Guru 72500 points

The best way to answer your question is to point you to the ARMv7 Architecture Reference Manual:
static.docs.arm.com/.../DDI0403E_B_armv7m_arm.pdf
To be specific, that instruction stores the contents of r0 at the location pointed to by the sum of the contents of r2 and the contents of r1 after it has been shifted left two places. Since the contents of r2 is odd and this is a 32-bit store, this is clearly an unaligned write.

0 PirateLeChuck over 7 years ago in reply to Bob Crosby

Intellectual 380 points

Thanks for the reply. Analyzing the C code a little bit further I found out that grantedQoSs is stored at address 0x20012AD1, which is not a valid address as far as I know.

The declaration is as follows:

typedef struct MQTTSubackData
{
    enum QoS grantedQoS;
} MQTTSubackData;

...

MQTTSubackData data;

0 PirateLeChuck over 7 years ago in reply to PirateLeChuck

Intellectual 380 points

Using compiler optimization level 0 solved the problem. Can I file a bug report for the compiler somewhere?

0 Bob Crosby over 7 years ago in reply to PirateLeChuck

TI__Guru 72500 points

First, what compiler are you using? I am not convinced this is a compiler issue. 0x20012AD1 is a valid RAM address. It may be a setting or type casting issue.

0 PirateLeChuck over 7 years ago in reply to Bob Crosby

Intellectual 380 points

I use CCS v8.

Best regards

0 Bob Crosby over 7 years ago in reply to PirateLeChuck

TI__Guru 72500 points

Yes, but which compiler did you use? You can find that by right clicking on your project in the "Project Explorer" window and selecting "Show Build Settings". In the image below it shows using the TI compiler version 16.9.4.

Can you provide more provide an example project that recreates this issue?

0 PirateLeChuck over 7 years ago in reply to Bob Crosby

Intellectual 380 points

My compiler version is TI v18.1.1 LTS. The project is an Eclipse Paho embedded C client for TI RTOS on TM4C1294XL.
The problem occures after accessing an int[] which was casted from an enum. I can provide an example project within the next days.

0 Bob Crosby over 7 years ago in reply to PirateLeChuck

TI__Guru 72500 points

I think you just told me the critical piece. By default the compiler uses packed enumerations. If the enum can be represented in 8 bits, it will be. That saves space, but allows enums to be on byte boundaries. When you cast the enum pointer to unsigned int pointer, you now have the compiler generating a 32-bit write to an odd byte boundary . You can change how enums are handled in the "ARM Compiler"->"Advanced Options"->"Runtime Model Options" settings. Change enum type from packed to int as shown. This causes some memory inefficiency. You might want to rewrite the code such you are casting the variable you are storing to the proper enum type before storing it.

0 PirateLeChuck over 7 years ago in reply to Bob Crosby

Intellectual 380 points

Thank you very much! This solved my issue in an elegant way. Thanks for the great support!

Best regards

Arm-based microcontrollers

Arm-based microcontrollers forum

EK-TM4C1294XL: STR.w leads to unaligned memory access