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: Failed to clear NewDat in CAN_IF2MCTL

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hi expert,

I am testing example project can_ex1_loopback to reproduce an issue from my customer. When reading a CAN Mailbox, we are instructed to clear NewDat in CAN_IF2MCTL register. We also have a driverlib API to do this automatically:

        // Now clear out the new data flag
        //
        HWREG_BP(base + CAN_O_IF2CMD) = ((uint32_t)CAN_IF2CMD_TXRQST |
                                        (objID & CAN_IF2CMD_MSG_NUM_M));

Problem is that this bit is not really cleared when executing this line. As shown below:

Any comments here?

Thanks

Sheldon

  • Hi expert,

    Any update here? It can be easily tested on TI's example project direstly with only put some break point and watch registers.

    Thanks

    Sheldon

  • is this as-is example from C2000Ware or modified ?

    is your data getting transferred correctly ?

    Check the newdata flag after the busy bit is cleared (line 583)

  • Hi Bask.

    This issue can be produced from C2000ware original example project, expecially for thouse using driverllib.

    C:\ti\c2000\C2000Ware_3_02_00_00\driverlib\f2838x\examples\c28x\can

    Data is getting transferred with sccess.

    I put break point at line 583 and 594 separately, this bit is still set.

    Thansk

    Sheldon

  • unfortunately i don't have the hw at this point to try out (as we are working remotely). i will check if any of my colleagues can check it.

    Since data is coming correctly i suppose you are not blocked on this.

  • Hi Bask,

    Please help me find someone who has a HW to spend 10 minutes to have a try! Though it doesn't block normal communication here, my customer need to know why it is different from who depict on our datasheet. 

    This is an automotive application so we need to take care and put everything to a known state.

    Thanks

    Sheldon

  • Hi Sheldon,

    I will look into this during my next lab visit.  We currently have lab access limitation as most of us are working remotely and we will have to schedule beforehand our lab times to ensure we meet the required personnel presence.

    I have a question on this though.  Can you please share the background that brought this issue at customer side?  Did they notice this during message reception?  If it was during reception, it is probably an indication that message is lost.  This can be confirmed by inspecting the contents of CAN_IFxMCTL MsgLst bit.  If this is set, meaning message is lost, NewDat will remain set.  Just a quick check that you can do.

    Nevertheless, I will let you know this week the result of my checkout on the HW once I get access to the lab.

    Regards,

    Joseph

  • Hi Joseph,

    To answer your questions:

    I have a question on this though. Can you please share the background that brought this issue at customer side?

    They just go into detials and find what they witnessed does not match what is said in TRM.

    Did they notice this during message reception?  If it was during reception, it is probably an indication that message is lost. 

    Yes, in message reception. 

    This can be confirmed by inspecting the contents of CAN_IFxMCTL MsgLst bit.  If this is set, meaning message is lost, NewDat will remain set.  Just a quick check that you can do.

    We have seen situations where CAN_IFxMCTL MsgLst not set while NewDat not get cleared.

    Please just try example project by putting break point in to have this reproduced.

    Thanks

    Sheldon

  • Hi Sheldon,

    Just reiterating what Chris indicated in the other email chain - NewDat is actually cleared in the message ram by running the driverlib function CAN_readMessage (when writing to CAN_IF2CMD register).   You have to look at the message ram data for the latest status of NewDat during reception when clearing NewDat using the driverlib function during reception.  Hope this clears up the issue.

    Regards,

    Joseph