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: EtherCAT slave stack Rx issue when running in CM core

Part Number: TMS320F28388D

Hi Champs,

My customer faced one issue on EtherCAT running in F2838x CM core. TX is working well, but RX has some problem. They found that F2838x receives the first data well from TwinCAT, but the next data are 16bit shifted.

They are suspicious of 8bit access of CM core in the following code. Could you help this issue?

 

/////////////////////// cia402appl.c//////////////////////////////////

void APPL_OutputMapping(UINT16* pData)
{
    UINT16 j = 0;
    UINT8 *pTmpData = (UINT8 *)pData;   // get 8bit data point because CM only supports 8bit access
    UINT8 AxisIndex;

    for (j = 0; j < sRxPDOassign.u16SubIndex0; j++)
    {
        /*The Axis index is based on the PDO mapping offset (0x10)*/
        AxisIndex = ((sRxPDOassign.aEntries[j] & 0xF0) >> 4);

        switch ((sRxPDOassign.aEntries[j] & 0x000F))
        {
        case 0:    //csp/csv RxPDO    entries
            {
            TCiA402PDO1600 *pOutputs = (TCiA402PDO1600 *)pTmpData;

            LocalAxes[AxisIndex].Objects.objControlWord = SWAPWORD(pOutputs->ObjControlWord);  // objControlWord 16bit data, but only 8bit data is stored and 16bit is pushed back
            LocalAxes[AxisIndex].Objects.objTargetPosition = SWAPDWORD(pOutputs->ObjTargetPosition);
            LocalAxes[AxisIndex].Objects.objTargetVelocity    = SWAPDWORD(pOutputs->ObjTargetVelocity);
            LocalAxes[AxisIndex].Objects.objModesOfOperation = SWAPWORD((pOutputs->ObjModesOfOperation & 0x00FF));

            /*shift pointer PDO mapping object following*/
            if (j < (sRxPDOassign.u16SubIndex0 - 1))
            {
                pTmpData += SIZEOF(TCiA402PDO1600);
            }
            }
            break;

///////////////////////////////////////////////////////////////////////

 

 

//////////////////////cia402appl.h////////////////////////////////////

/** \brief Data structure to handle the process data transmitted via 0x1600 (csp/csv RxPDO)*/
typedef struct STRUCT_PACKED_START
{
    UINT16 ObjControlWord; /**< \brief Control word (0x6040)*/
    INT32 ObjTargetPosition; /**< \brief Target position (0x607A)*/
    INT32 ObjTargetVelocity; /**< \brief Target velocity (0x60FF)*/
    INT16 ObjModesOfOperation; /**< \brief Mode of operation (0x6060)*/
}STRUCT_PACKED_END
TCiA402PDO1600;

///////////////////////////////////////

  • Steve

    Are you saying that you set a 16-bit value from TwinCAT, you see value correctly in TwinCAT, but the value is incorrect in the LocalAxes[AxisIndex].Objects.objControlWord ?

    If so, I'm not reproducing that. If set 0xFFFF in controlword via TwinCAT, it is being updated corrected in the LocalAxes object.

    Please clarify if I'm misunderstanding the issue.

    Best regards

    Chris

  • Chris,

    The data packet consists of four object variables. The first 16-bit value (Objects.objControlWord) is correct. But, the next 32-bit data, Objects.objTargetPosition and Objects.objTargetVelocity seem to be shifted and incorrectly stored in these variables.

    Thanks,

    Steve

  • Steve

    Ok, understood. I reviewed and it looks like the CiA402 code expects structs to be packed and this isn't set by default.

    In the ecat_def.h, locate the #define STRUCT_PACKED_END and set __attribute__((packed))

    Will look like:

    #ifndef STRUCT_PACKED_END
    #define STRUCT_PACKED_END __attribute__((packed))
    #endif

    This looks to have corrected the issue on my end, see if that fixes it for you.

    Best regards

    Chris

  • Chris,

    Thanks for your feedback. Your solution worked in my side as well. 

    There are three defines of struct in the ecat_def.h as following. Do I have to add "__attribute__((packed))" to all three defines?

    The customer found that the stack code generated for ST-micro has "__attribute__((packed))" in all three START defines instead of END. Ar both same?

    Also, I think this solution should be enabled by default from Backup's SST Tool.

    //-------------------------------------------------------------------------------------------

    #ifndef STRUCT_PACKED_START
    #define STRUCT_PACKED_START
    #endif

    #ifndef STRUCT_PACKED_END
    #define STRUCT_PACKED_END __attribute__((packed))
    #endif

    #ifndef MBX_STRUCT_PACKED_START
    #define MBX_STRUCT_PACKED_START
    #endif

    #ifndef MBX_STRUCT_PACKED_END
    #define MBX_STRUCT_PACKED_END __attribute__((packed))
    #endif

    #ifndef OBJ_STRUCT_PACKED_START
    #define OBJ_STRUCT_PACKED_START
    #endif

    #ifndef OBJ_STRUCT_PACKED_END
    #define OBJ_STRUCT_PACKED_END __attribute__((packed))
    #endif

    //------------------------------------------------------------------------------------------

  • Steve

    Great!

    As far as I'm aware, START vs the END is the same. Maybe some compilers prefer one location over the other. From my typical usage, the END location made more sense.

    I don't have any tests to say, but it likely is best to use the attribute for all 3 locations.

    Yes I agree it should be enabled by default in the SSC tool. I don't see a way to configure when generating the SSC code unfortunately. 

    Best regards

    Chris 

  • Chris,

    It turns out that the attribute for all 3 locations makes some issue. It leads Rx data's malfunction. Hence, I applied the attribute to only STRUCT_PACKED_END. It works fine. As mentioned early, ST-micro uses the attributes for all 3 positions. But, we have to applied only one attribute. I couldn't find the reason. 

    It' not urgent, but If you have a chance to review it, pls take look at this difference.

    Regards,

    Steve

  • Steve

    Alright, thanks for the update!

    I would assume those other structs don't need to be packed for how they capture data in the EtherCAT RAM. I will make a note to look into it on my backlog but please don't let that information block you all from continuing testing/development.

    Best regards

    Chris