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.

TMS320F28035: CAN data is abnormal if sending mailbox is 15

Part Number: TMS320F28035
Other Parts Discussed in Thread: C2000WARE

Hi,

My customer use mailbox 16 and 15 as the receiving and sending mailbox respectively.

On production line, we find that half product sending data are abnormal. Data frame became to remote frame.

After change the sending mailbox from 15 to 14, it return to working well.

Attach CAN configuration code. In InitECana function, all mailbox control remote frame bits (RTR) has been cleared to '0'.

Could you kindly give some comments about why it has problem if sending mailbox is 15? Thanks.

void Can_Config(void)
{
 InitECanaGpio();
 InitECana();
 DCDC_3KW_CANTransmit_Init();
 DCDC_3KW_CANReceive_Init();
 DCDC_3KW_Init_ECana_INT();
 LogDataMboxInit();
 Init_CAN_RcvBuf()
}
 
 
void LogDataMboxInit(void)
{
 union CANLAM_REG ECanaLAMShadow;
 ECanaMboxes.MBOX16.MSGID.all = LOG_Rx_ID;
 ECanaLAMShadow.all           = ECanaLAMRegs.LAM16.all;
 ECanaLAMShadow.bit.LAMI      = 1;         // Keep same with mailbox 15 identifier, receive if same
 ECanaLAMShadow.bit.rsvd1     = 3;         // Reserved bit, invalid write
 ECanaLAMShadow.bit.LAM_L     = 0x0000;    // Low bytes for comparison
 ECanaLAMShadow.bit.LAM_H     = 0x0000;    // High bytes for comparison
 ECanaLAMRegs.LAM16.all       = ECanaLAMShadow.all;
 
 

 ECanaMboxes.MBOX15.MSGID.all = LOG_Tx_ID;
 
 ECanaShadow.CANMD.all = ECanaRegs.CANMD.all;
 ECanaShadow.CANMD.bit.MD15   = 0;         // Transmit mailbox
 ECanaShadow.CANMD.bit.MD16   = 1;         //Receive  mailbox 
 ECanaRegs.CANMD.all = ECanaShadow.CANMD.all;
 
 ECanaShadow.CANME.all = ECanaRegs.CANME.all;
 ECanaShadow.CANME.bit.ME15 = 1;
 ECanaShadow.CANME.bit.ME16 = 1;
 ECanaRegs.CANME.all = ECanaShadow.CANME.all;
 
    struct ECAN_REGS ECanaShadow;
    EALLOW;
 //
    ECanaShadow.CANMIM.all=ECanaRegs.CANMIM.all;  //
    ECanaShadow.CANMIM.bit.MIM16=1;
    ECanaRegs.CANMIM.all= ECanaShadow.CANMIM.all;
//
    ECanaShadow.CANMIL.all=ECanaRegs.CANMIL.all;
    ECanaShadow.CANMIL.bit.MIL16=0;
    ECanaRegs.CANMIL.all=ECanaShadow.CANMIL.all;
//
    ECanaShadow.CANGIM.all=ECanaRegs.CANGIM.all;
    ECanaShadow.CANGIM.bit.AAIM=0;  //
    ECanaShadow.CANGIM.bit.BOIM=0;  //
    ECanaShadow.CANGIM.bit.EPIM=0;  //
    ECanaShadow.CANGIM.bit.WDIM=0;  //
    ECanaShadow.CANGIM.bit.WUIM=0;  //
    ECanaShadow.CANGIM.bit.WLIM=0;  //
    ECanaShadow.CANGIM.bit.I0EN=1;  //
    ECanaShadow.CANGIM.bit.I1EN=0; //
    ECanaShadow.CANGIM.bit.GIL=0;   //
    ECanaShadow.CANGIM.bit.MTOM=0;  //
    ECanaShadow.CANGIM.bit.RMLIM=0;  //
    ECanaShadow.CANGIM.bit.TCOM=0;   //
    ECanaRegs.CANGIM.all=ECanaShadow.CANGIM.all;
    EDIS;

}

  • Daniel,

    What you say should not be happening. All 32 mailboxes are exactly identical and should behave the same way. Did you take a look at the debug tips in my app.note SPRA876?

    In the InitECana() function, the MSGCTRL register is written with 0x0000000 by an instruction like ECanaMboxes.MBOX15.MSGCTRL.all = 0x00000000; After the function is executed, did you verify that the MSGCTRL register is actually holding 0x0000000? Note that the RTR bit (which determines whether a frame is a Data frame or  a Remote frame) is part of the MSGCTRL register. When MSGCTRL register is subsequently written to configure DLC, does customer use 32-bit write? Send the screen capture that shows the MSGCTRL value of mailbox 15 when this problem happens.

  • Hi Hareesh,

    We have gotten the root cause. Register MSGCTRL can not be changed if set mailbox to receiving and enabled mode, the value can be changed only if set it to disabled.

    In customer boot code, it set mailbox 15 to to receive and enabled. But in customer application code, set mailbox 15 to send. 

    We call InitECana() function to set MSGCTRL, then disable all mailbox by ECanaRegs.CANME.all = 0;

    Because mailbox 15 is still stay at enable mode, so can't set MSGCTRL to 0.

    One question is 

    On F28035 manual, I only see that the ID need to be disabled before write. Is it same on MSGCTRL register?

    Our plan is to modify InitECana(), put the disable code from the end to the first. Is it OK?

    What's the default value of MSGCTRL after power on?

    void
    CAN_clearMessage(uint32_t base, uint32_t objID)
    {
        //
        // Check the arguments.
        //
        ASSERT(CAN_isBaseValid(base));
        ASSERT((objID >= 1U) && (objID <= 32U));
     
        //
        // Wait for busy bit to clear
        //
        while((HWREGH(base + CAN_O_IF1CMD) & CAN_IF1CMD_BUSY) == CAN_IF1CMD_BUSY)
        {
        }
     
        //
        // Clear the message valid bit in the arbitration register. This indicates
        // the message is not valid.
        //
        HWREG_BP(base + CAN_O_IF1ARB) = 0U;
        HWREG_BP(base + CAN_O_IF1CMD) = (CAN_IF1CMD_DIR | CAN_IF1CMD_ARB);
     
        //
        // Initiate programming the message object
        //
        HWREGH(base + CAN_O_IF1CMD) = objID & CAN_IF1CMD_MSG_NUM_M;
    }
    

    About F280049 MsgVal. Is it only need to call CAN_clearMessage before configure CAN? Thanks.

  • Please create a new post for question regarding 280049 CAN.

  • We call InitECana() function to set MSGCTRL, then disable all mailbox by ECanaRegs.CANME.all = 0; Because mailbox 15 is still stay at enable mode, so can't set MSGCTRL to 0.

    The above is confusing. How could MBX15 "still stay at enable mode" when CANME.all = 0 ?

     

    On F28035 manual, I only see that the ID need to be disabled before write. Is it same on MSGCTRL register?

    I need to test this on silicon. 

    Our plan is to modify InitECana(), put the disable code from the end to the first. Is it OK?

    The InitECana() function is run during device initialization, when mailboxes are already disabled. So, I think disabling the mailboxes early on in that function should make no difference. Do test it out on silicon though. 

    What's the default value of MSGCTRL after power on?

    Undefined. That is why the InitECana() function initializes all bits to zero.

  • Hi Hareesh,

    Close this thread now.

    Let's move to a new post because it's a new question. Thanks for your support.

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/819361

  • You wanted to know whether the MBX needs to be disabled in order to update the MSGCTRL field. I tried this on silicon. I am able to update the MSGCTRL field, regardless of whether the MBX is enabled or not. You can test this yourself with the following code snip (just insert this snip into the C2000ware example)

        InitECana();            // Initialize eCAN-A module
    
        EALLOW;
        ECanaRegs.CANME.all = 0xFFFFFFFF;
        ECanaMboxes.MBOX0.MSGCTRL.bit.DLC = 1;
        asm("  NOP;");
        ECanaRegs.CANME.all = 0x00000000;
        ECanaMboxes.MBOX0.MSGCTRL.bit.DLC = 2;
        asm("  NOP;");

     

  • Hi Hareesh,

    The problem what we met is MSGCTRL can't be updated after set mailbox to receive and enabled.

    Your code above is initialization, don't set it to receive. 

    a. Set it to receive mailbox, enable. MSGCTRL CAN NOT be updated

    b. Set it to send mailbox, enable. MSGCTRL can be updated

  • Please help me understand why you need to modify MSGCTRL for a Receive mailbox. TPL & DLC bit fields are only applicable for a Transmit mailbox. You can set the RTR bit for a Receive mailbox (to send a Remote frame request), but that could be done before enabling the mailbox.

  • Hi Hareesh,

    My customer purpose is dynamically set mailbox.

    Set to receive mailbox firstly, then change to send mailbox when meet some condition. Do not modify MSGCTRL for a receive mailbox.

    In Flash boot:

    a) Set 15 as receive mailbox.

    b) Enable.

    Then jump to customer application code, set 15 as send mailbox

    c) MSGCTRL=0

    d) Disable

    My question is in the case of set it to receive and enable.

    MSGCTRL (or which of them) can not be updated? Does it must be disabled and then updated? Thanks.

  • Hi,

    Is there any feedback or still anything unclear? Thanks.

  • I have already clarified that mailbox need not be disabled for updating MSGCTRL. You mentioned that it needs to be disabled in the case of Rcv mailbox. MSGCTRL is not useful for a Receive mailbox (unless used to transmit a remote frame). Write access to MSGCTRL in the case of a Receive mailbox is not defined in the spec. It could be that the mailbox needs to be disabled. If so, it needs to be incorporated into the code.