TMS320F28379D: Strange processor behavior: wrong instruction execution ?

Alex Guryanow

Part Number: TMS320F28379D

I have a local variable uint16_t* buf pointing to CPU1 to CPU2 Message RAM. The code is executed on CPU2 from RAM. I want to interpret first two elements of buf[ ] as uint32_t, so I wrote in C:

address = *((uint32_t*)buf);

But unfortunatelly I got unexpected result in the local variable "uint32_t address". I started debugging and stumbled over some unexpected behavior, that I can't understand. The code above was compiled to the following sequence of assembler instructions:

MOVL ACC,*+XAR4[0] ; [CPU_ALU] |204|
MOVL *-SP[4],ACC ; [CPU_ALU] |204|

But running this code step by step I get strange results. It seems to me that first instruction is executed wrong. Here is a screenshot before execting first instruction:

Here is screenshot after "Assembly step into":

I expected that ACC register will contain 0x082000 after executing first assembly instruction, but it contains 0x20000081. How can it be possible ?

Regards,

Alex

over 4 years ago

0 Alex Guryanow over 4 years ago

Prodigy 110 points

I have replaced the code

address = *((uint32_t*)buf);

with

address = buf[1];
address <<= 16;
address |= (buf[0] & 0x0000FFFFUL);

and now the program works correctly. But I don't understand what's wrong with the first variant.

Regards,

Alex

0 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

Hi Alex,

Since this variable is placed in MSG RAM which can be updated from CPU1, you may want to use the volatile and see if that solves the issue.

Regards,

Vivek Singh

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Hi Vivek,

what variable do you mean? Do you mean using volatile for the pointer "buf" or for the variable it points to? Actually "buf" is function argument.

I thought that volatile is important at compile time but not at run time. In my opinion volatile syas to the compiler that the variable cannot be cached and read access to it cannot be optimized. Am I wrong?

As you can see on screenshots, XAR4 register points to correct address (compare it with expression "&buf[0]"). Before executing the instruction "MOVL ACC,*+XAR4[0]" the ACC register was manually filled with the fake value 0xA5A5A5A5A5 and after executing specified instruction it contains 0x20000081. It means that ACC was updated during execution of this instruction. At the same time expression "*((uint32_t*)buf)" (in Expressions tab) shows corrent value 0x82000. This value is displayed before and after executing "MOVL ACC,*+XAR4[0]".

Regards,

Alex

0 Alex Guryanow over 4 years ago in reply to Alex Guryanow

Prodigy 110 points

Vivek Singh said:
which can be updated from CPU1

I halted CPU1 before executing "MOVL ACC,*+XAR4[0]" - the result is the same - I got wrong value in ACC register (0x20000081 instead of 0x82000). So it cannot be changing of MSG RAM from CPU1.

The debug tab Expressions shows the value 0x00082000 for expression *((uint32_t*) 0x3FC01) on both CPU.

Regards,

Alex

0 Alex Guryanow over 4 years ago in reply to Alex Guryanow

Prodigy 110 points

Сan this be related to 32-bit access at an odd address ?

0 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

I am also looking at the address alignment. What is the value in buf[2] ?

0 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

You are right about volatile making a difference at compile time only and runtime. I was only thinking is for some reason CPU1 is updating the same location when you are reading it but your new post confirm that this is not the issue.

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Vivek Singh said:
I am also looking at the address alignment. What is the value in buf[2] ?

buf[2] == 0x0010

0 Vivek Singh over 4 years ago in reply to Vivek Singh

TI__Guru** 116021 points

Also can you check your compile log and see if there are any warnings ?

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Vivek Singh said:
Also can you check your compile log and see if there are any warnings ?

There aren't any warnings.

0 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

And what is the value at 0x3FC00 ?

+1 Alex Guryanow over 4 years ago in reply to Alex Guryanow

Prodigy 110 points

Alex Guryanow said:
Сan this be related to 32-bit access at an odd address ?

I think I got it. I have found the following for CLA:

Like the C28x CPU, the CLA expects memory logic to align any 32-
bit read or write to an even address. If the address-generation logic generates an odd address, the CLA
will begin reading or writing at the previous even address.

TRM, part 6.3.2 CLA Memory Bus

The value _before_ buf[0] is 0x0081. So reading from 0x0x3FC00 (instead of 0x3FC01) gives the value 0x20000081.

So it seems that C28x reads from "the previous even address". But I searched TRM for substrings "odd address" and "even address" and didn't find such a information regarding 32-bit memory access on C28x, only regarding CLA, CAN and USB.

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Vivek Singh said:
And what is the value at 0x3FC00 ?

You are right. There is 0x0081

0 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

Ok, so basically what is happening is when one tries to access 32 bit value at odd address, it coverts the odd address into even address and then gives the value from there which is address 0x3FC00 in this case. Compiler should have given some warning in this case but since it's not, there may be some switch to enable such warning. I'll have to refer to our compiler team on this.

Regards,

Vivek Singh

0 Vivek Singh over 4 years ago in reply to Vivek Singh

TI__Guru** 116021 points

Can you try adding below line after buf declaration and see if this fixes the issue-

#pragma DATA_ALIGN(buf,2);

Regards,

Vivek Singh

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Sorry but I don't understand where should I put this pragma.

I have defined a struct type

typedef struct {
uint16_t BL_cmd;
uint16_t BL_data[20];
} C1C2_MSG_t;

and global variable с1с2_msg of this type that is put to address 0x3FC00 using .cmd file. "buf" is a uint16_t* argument of a function:

void my_func(uint16_t* buf)

{

...

}

This function is called like

...

my_func( c1c2_msg.BL_data );

...

Regards,

Alex

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Vivek Singh said:
what is happening is when one tries to access 32 bit value at odd address, it coverts the odd address into even address

Where is this described? In what document?

+1 Vivek Singh over 4 years ago in reply to Alex Guryanow

TI__Guru** 116021 points

Alex Guryanow said:
Where is this described? In what document?

Please see section "1.4.3 Alignment of 32-Bit Accesses to Even Addresses" in CPU User Guide.

Alex Guryanow said:
Sorry but I don't understand where should I put this pragma.

I think in this case you need to do that for BL_data or move it definition before BL_cmd. Since you have one 16bit variable, the array is getting placed at odd address.

Regards,

Vivek Singh

0 Vivek Singh over 4 years ago in reply to Vivek Singh

TI__Guru** 116021 points

Hi Alex,

Let me know if you have any further query on this.

Regards,

Vivek Singh

+1 George Mock over 4 years ago in reply to Alex Guryanow

TI__Guru**** 251760 points

When you write this code ...

Alex Guryanow said:
address = *((uint32_t*)buf);

... you tell the compiler that you accept responsibility for making sure the alignment constraints of uint32_t are met by buf, prior to execution of this statement. But you haven't done that. You create this structure ...

Alex Guryanow said:
typedef struct {
uint16_t BL_cmd;
uint16_t BL_data[20];
} C1C2_MSG_t;

and an instance of this structure ...

Alex Guryanow said:
global variable с1с2_msg of this type that is put to address 0x3FC00 using .cmd file

Then you write ...

Alex Guryanow said:
my_func( c1c2_msg.BL_data );

Taken together, these steps guarantee that buf has the odd address 0x3fc01, which is not aligned as uint32_t requires.

One solution to consider is to add a field to the structure to force the required alignment ...

typedef struct {
    uint16_t BL_cmd;
    uint16_t never_used;  /* to force alignment */
    uint16_t BL_data[20];  
} C1C2_MSG_t;

You have already discovered the other solution, which is to not presume buf is aligned and write code similar to ...

Alex Guryanow said:
address = buf[1];
address <<= 16;
address |= (buf[0] & 0x0000FFFFUL);

Thanks and regards,

-George

0 Alex Guryanow over 4 years ago in reply to Vivek Singh

Prodigy 110 points

Vivek Singh said:
Please see section "1.4.3 Alignment of 32-Bit Accesses to Even Addresses" in CPU User Guide.

Thank you

Regards,
Alex

0 Alex Guryanow over 4 years ago in reply to George Mock

Prodigy 110 points

Hi George,

thank you for the full explanation and second solution.

Regards,

Alex

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: Strange processor behavior: wrong instruction execution ?