One Bug ? C6000 Code Generation Tools 7.2.0B2 on C6747

From the information given I cannot say for sure if it is a bug or not, but it does seem worthy of a full bug report.

All the data members of tRecvPkt.tHead are at the start of the tRecvPkt and have nice fullword sizes, so I do not see how packed would cause mischief with the ulCmd member except by allowing tRecvPkt to be allocated on a non-32-bit-aligned boundary.  (I am assuming the packed attribute is on the type OMB_OMBTASK_PACKET_CMD_AP_SET_....)  We would need to work with a detailed example to know more.  There is some possibility that the CCS display is wrong due to some kind of miscommunidation between the compiler and debugger, but I doubt it.

Is there any chance that the device or EMIFA are not happy about unaligned addresses and are thus somehow behind what we see here?

Hi Paul,

As you said , tRecvPkt.Head is located in SDRAM on a non-32-bit-aligned boundary.

tRecvPkt was just allocated within the stack as a local variable.

During the framework execution, a packet from a communication device (Ethernet module) memory mapped on the 16 bits EMIFA is copied in SDRAM using a basic memcpy().

Afterwards, the state of the communication device is read within the packet using the code:

state = tRecvPkt.tHead.ulcmd;

Best regards,

Frederic

typedef struct __attribute__((__packed__)) OMB_OMBTASK_DATA_CMD_AP_SET_CONFIGURATION_REQ_Ttag
{
    TLR_UINT32 ulSystemFlags;
    TLR_UINT32 ulWdgTime;
    OMB_OMBTASK_CONFIG_T tOmbConfig;
    TCPIP_DATA_IP_CMD_SET_CONFIG_REQ_T tTcpConfig;
    TLR_UINT32 ulFlags;
} OMB_OMBTASK_DATA_CMD_AP_SET_CONFIGURATION_REQ_T;

typedef struct __attribute__((__packed__)) OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_Ttag
{
    TLR_PACKET_HEADER_T tHead;
    OMB_OMBTASK_DATA_CMD_AP_SET_CONFIGURATION_REQ_T tData;
} OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T;

/* packet header definition */
typedef struct
{
  TLR_UINT32  ulDest;   /* destination of the packet (task message queue reference) */
  TLR_UINT32  ulSrc;    /* source of the packet (task message queue reference) */
  TLR_UINT32  ulDestId; /* destination reference (internal use for message routing) */
  TLR_UINT32  ulSrcId;  /* source reference (internal use for message routing) */
  TLR_UINT32  ulLen;    /* length of packet data (starting from the end of the header) */
  TLR_UINT32  ulId;     /* identification reference (internal use by the sender) */
  TLR_UINT32  ulSta;    /* operation status code (error code, initialize with 0) */
  TLR_UINT32  ulCmd;    /* operation command code */
  TLR_UINT32  ulExt;    /* extension count (nonzero in multi-packet transfers) */
  TLR_UINT32  ulRout;   /* router reference (internal use for message routing) */
} TLR_PACKET_HEADER_T;

void main(void) {

        int32_t lRet;
        OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T o = {0};
        OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T tRecvPkt = {0};

......

..................

patching the TLR_PACKET_HEADER_T to use attribute packed does the same....

using #pragma DATA_ALIGN (4); also.....

same behaviour. The tRevPkt structure is still allocated on a non 32 bit boundary

.Frederic

/* packet header definition */
typedef struct __attribute__((__packed__))
{
  TLR_UINT32  ulDest;   /* destination of the packet (task message queue reference) */
  TLR_UINT32  ulSrc;    /* source of the packet (task message queue reference) */
  TLR_UINT32  ulDestId; /* destination reference (internal use for message routing) */
  TLR_UINT32  ulSrcId;  /* source reference (internal use for message routing) */
  TLR_UINT32  ulLen;    /* length of packet data (starting from the end of the header) */
  TLR_UINT32  ulId;     /* identification reference (internal use by the sender) */
  TLR_UINT32  ulSta;    /* operation status code (error code, initialize with 0) */
  TLR_UINT32  ulCmd;    /* operation command code */
  TLR_UINT32  ulExt;    /* extension count (nonzero in multi-packet transfers) */
  TLR_UINT32  ulRout;   /* router reference (internal use for message routing) */
} TLR_PACKET_HEADER_T;

I think this needs to be submitted as a full bug report.  Somewhere on this forum there are directions on how to do that.  GeorgeM will probably remind us again here.

Paul Knueven said:

I think this needs to be submitted as a full bug report.  Somewhere on this forum there are directions on how to do that.

See the last part of the forum welcome post.

Thanks and regards,

-George

Frederic,

One other possibility...

Defect SDSCM00038447 was a bug whose symptom was doing an aligned access to an unaligned address. It is fixed in 7.2.0B3 so you might try moving up to B3.

The cases in which that bug would appear are hard to describe in terms of the user source as it would occur only in certain optimization situations.

I think it would be worth trying B3 if you can do that.

OK thanks.

I had a look to : https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/beta.htm

B3 seems not yet available to download.

Can you provide me a link soon ?

Best regards,

Frederic

It turns out B2 will be the last beta release for v7.2.x .  The v7.2.0 production release should become available this week.

Thanks and regards,

-George

some news with 7.2.0 release:

#pragma DATA_ALIGN(o, 32);
static     OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T o = {0};
#pragma DATA_ALIGN(tRecvPkt, 32);
static    OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T tRecvPkt = {0};


static uint32_t envoyerLaConfigOpenModbus(bcc_if_eth2_conf_t * pc) {

..........

state = LE32_TO_HOST(tRecvPkt.tHead.ulCmd);  // this works

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

static uint32_t envoyerLaConfigOpenModbus(bcc_if_eth2_conf_t * pc) {

OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T o = {0};

OMB_OMBTASK_PACKET_CMD_AP_SET_CONFIGURATION_REQ_T tRecvPkt = {0};

state = LE32_TO_HOST(tRecvPkt.tHead.ulCmd);  // this does not work because of an automatic alignement on a 8bit boundary.