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.

c66x invalid pointer-to-a-pointer to a struct with bit fields

Other Parts Discussed in Thread: SYSBIOS

TI Compiler Experts-


We're using c6678 and CGT 7.4.2 (command line tools) and we see the following issue.  In the code below p1 and p2 should return the same value (pointing to a location in DDR3 mem, where the "session_data" array is located) and most of the time they do.  However, intermittently p1 gives a location in an invalid memory area (for example 0x007cxxxx):

   p1 = (uint8_t*)&ChanInfo_Core[n].link->term->term_id;
   p2 = (uint8_t*)&session_data[n].term.term_id;

The ChanInfo_Core struct "link" pointer points to another ChanInfo_Core struct, and inside that the "term" pointer points to a struct that looks like this:

typedef struct {

  uint32_t term_id;
  uint32_t  media_type : 8;
  uint32_t  codec_type : 8;
  uint32_t vqe_processing_interval : 16;
  uint32_t bitrate;

  struct ip_addr remote_ip;
  struct ip_addr local_ip;
  uint32_t remote_port : 16;
  uint32_t local_port : 16;

  union {
     struct voice_attributes voice_attr;
     struct video_attributes video_attr;
  } attr;

} HOST_TERM_INFO;

and session_data is an array of HOST_TERM_INFO structs.  We never see p2 with a bad value.  p1 and p2 are calculated in a SYSBIOS task that can be pre-empted, so we're concerned that "pointer to a pointer to a struct containing bit-fields" is generating code that is not atomic and not always reliable.  We have a lot of these and similar constructs in our application.

Is there some known advice for this situation ?  Avoid bit-fields ?  Use padding to adjust struct element alignment ?  Alignment of individual structs in the session_data array ?   Fewer levels of pointer-to-a-pointer ?

We are testing this on one core, with L2 cache enabled.

Thanks in advance for your help.

-Jeff
Signalogic

PS. We saw this thread:

  e2e.ti.com/.../278642

but it seems that was a case of the "pointer is always wrong", not intermittently.

  • Intermittent failures often indicate a hardware problem.  That said, this ...

    Jeff Brower73 said:
    we're concerned that "pointer to a pointer to a struct containing bit-fields" is generating code that is not atomic and not always reliable.

    ... is a possibility.  I think it is unlikely.  There is not enough here to act on.  I realize it is difficult, but I think the next step is for you to inspect the compiler generated assembly code and see if you can spot possible trouble spots.

    Another suggestion ... Try using a lower --opt_level option.  That is not a long term fix, but a possible workaround.

    Thanks and regards,

    -George

  • George-


    Thanks.  Yes we will try running at lower CPU and DDR3 clock rates, reduce -opt level, and look at generated code, and come back with more info.

    -Jeff

  • George-

    Update -- we were able to build up a suite of internal memory diagnostics that allowed us to finally figure out the underlying root cause -- a very low error rate / intermittent DDR3 mem problem on the board. The error rate is so low the hardware manufacturer's mem stress test program could not detect the problem. In addition to the diagnostics, we also found a way to force a higher error rate.

    Running at reduced DDR3 clock rate is a temporary work-around.

    -Jeff
  • Thank you for the update!  -George

  • George-


    Sure.  I was trying to verify your answer but "Verify Answer" is not showing up.

    -Jeff

  • Jeff Brower73 said:
    Sure.  I was trying to verify your answer but "Verify Answer" is not showing up.

    That is because this thread was classified as a "Discussion" and not a "Question".  I fixed that, then marked my first response as the answer.

    Thanks and regards,

    -George