• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 244 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: Questions about f2838x_cm_cia402_solution routine aPdOutputData array data processing

Susan Ren
Prodigy 345 points

Part Number: TMS320F28388D

Hi Team,

The aPdOutputData array is used to store the data issued by the master, and the data in EtherCAT is in the small-endian mode:

Taking the CSV\/CSP mode I am using now as an example, the RxPDO channel binding relationship is:

index6040 is the status word object index, the data bit width is 16 bits; index607A is the TargetPosition object index, the data bit width is 32 bits; index60FF is the TargetVelocity object index, the data bit width is 32 bits; index6060 is the schema object index, and the data bit width is 8 bits

According to the little-endian pattern, the order of the received data in memory should be:

Byte1 status word【0】

Byte2 status word【1】

Byte3 TargetPosition【0】

Byte4 TargetPosition【1】

Byte5 TargetPosition【2】

Byte6 TargetPosition【3】

Byte7 TargetPosition【0】

Byte8 TargetPosition【1】

Byte9 TargetPosition【2】

Byte10 TargetPosition【3】

Byte11 mode 【0】

APPL_OutputMapping function does call swapWORD, SWAPDWORD function when processing data:

SWAPWORD: (Function definitions are found from the web)

SWAPDWORD: (Function definitions are found from the web)

After processing the SWAP function, the corresponding object can get the correct value.

But during debugging, I saw something like this:

The TargetPosition value I set is 500000, which is 0x0007 A120

Question 1. It is found that the order of TargetPosition in memory has been arranged before calling the SWAPDWORD function, which is why;

Question 2. In this debugging interface, without using the SWAPDWORD function, it is found that the TargetPosition object can also get 5000000, that is, the 0x0007 A120 value, why is this?

I understand that after being processed by the swap function, the order of the data in memory should be:

Byte1 status word【1】

Byte2 status word【0】

Byte3 TargetPosition【3】

Byte4 TargetPosition【2】

Byte5 TargetPosition【1】

Byte6 TargetPosition【0】

Byte7 TargetPosition【3】

Byte8 TargetPosition【2】

Byte9 TargetPosition【1】

Byte10 TargetPosition【0】

Byte11 mode 【0】

If this data is passed to C28 in the form of Uint16 via interprocess communication, the order I understand is as follows:

Word1 Status Word[1]Status Word【0】

Word2 TargetPosition【3】TargetPosition【2】-----> 0x0007

Word3 TargetPosition【1】TargetPosition【0】-----> 0xA120

Word4 TargetPosition【3】TargetPosition【2】

Word5 TargetPosition【1】TargetPosition【0】

However, from the debugging results, the C28 side is in this data order:

namely

Word2 TargetPosition【3】TargetPosition【2】-----> 0xA120

Word3 TargetPosition【1】TargetPosition【0】-----> 0x0007

Question 3. Please ask why

Thanks，

Susan Ren

  • +1
    TI__Mastermind 45606 points

    Hi Susan,

    I'm not able to read your images clearly, so I can't understand all the details. I think the below may clear up some things however.

    Please note that the SWAPWORD macro in ecatslv.h just returns the same value. It doesn't actually seem to do anything, see below.

    #ifndef SWAPWORD
    #define    SWAPWORD(x)                        (x) /**< \brief Macro to swap a WORD*/
#endif

    I'm not sure why the code is written this way. Keep in mind that the SW stack and sample code is written by Beckhoff, not TI, so you may have to ask them if you'd like further understanding.

    Best,

    Kevin