Interfacing TMS320F28335 with CANape

JFin,

The CAN data registers are 32 bits wide and can easily be read out a byte at a time.  Could you give me a more concrete example of how your data is being messed up?  If I can better understand the problem I'm sure I can suggest a solution for you.

Regards,

Hi.

JFin said:

One of things that I have noticed is that 1-byte is 16-bits on the f28335, but it appears that 1-byte is only 8-bits inside of the ASAP2 definition file that everything else uses

If you're going to use a data structure, try to specify length of field in bits:

struct my_st {
   Uint16 field1:8;
   Uint16 field2:8;
   Uint16 field3:8;
   Uint16 field4:8;
}

Then operate over it via memcpy or type casting. You may also access individual bytes in eCAN registers' fields: MDL and MDH.

PS. sizeof(char) and sizeof(int) is equal, because TMS320's memory is 16 bits wide.

Please, describe in details how do you access eCAN data in your program and where you mess data.

Trey,

  Playing around more with this I see the issue on sending from the f28335 and receiving into the f28335.  Here is an example of what I am seeing when trying to attempt the connection between the two by sending a message to CANape with the ubData message I have stored:

  Running a function that has been created called 'CANConfigMsgObj'

void CANConfigMsgObj(can_description_t *pcdesc, uint8_t ubObjNr, TCAN_SWObj *pstObj)
{
    struct ECAN_REGS Shadow;
    union LAM_REGS LAM;
    struct MBOX Box;

    CANRequestMsgObj(pcdesc, ubObjNr);                                      /* get CPU control of the mailbox */

    Box.MSGID.all = 0;
    Box.MSGID.bit.STDMSGID = pstObj->ulMSGID;
    pcdesc->port.pMbxs[ubObjNr].MSGID.all = Box.MSGID.all;
    LAM.LAM[ubObjNr].all = 0;
    pcdesc->port.pLAM->LAM[ubObjNr].all = LAM.LAM[ubObjNr].all;
    if (pstObj->fTransmit)
    {
        Box.MSGCTRL.bit.DLC = pstObj->uwLength; 
        Box.MSGCTRL.bit.RTR = 0;
        Box.MSGCTRL.bit.TPL = (ubObjNr & 0x1F);
        pcdesc->port.pMbxs[ubObjNr].MSGCTRL.all = Box.MSGCTRL.all;
        Shadow.CANMD.all = pcdesc->port.pPort->CANMD.all;
        Shadow.CANMD.all &= ~(1 << ubObjNr);
        pcdesc->port.pPort->CANMD.all = Shadow.CANMD.all; 

        Box.MDL.all = (((uint32_t)pstObj->ubData[0]& 0xFF) << 24) |
                                  (((uint32_t)pstObj->ubData[1]& 0xFF) << 16) |
                                  (((uint32_t)pstObj->ubData[2]& 0xFF) << 8) |
                                 ((uint32_t)pstObj->ubData[3]& 0xFF);
        pcdesc->port.pMbxs[ubObjNr].MDL.all = Box.MDL.all;

        Box.MDH.all = (((uint32_t)pstObj->ubData[4]& 0xFF) << 24) |
                                   (((uint32_t)pstObj->ubData[5]& 0xFF) << 16) |
                                   (((uint32_t)pstObj->ubData[6]& 0xFF) << 8) |
                                   ((uint32_t)pstObj->ubData[7]& 0xFF);
         pcdesc->port.pMbxs[ubObjNr].MDH.all = Box.MDH.all;

    }
CANReleaseObj(pcdesc, ubObjNr);
} /* End of function CANConfigMsgObj */

  In ubData I have stored:

  ubData[0] = 0x04FF

  ubData[1] = 0x0882

  ubData[2] = 0x0008

  ubData[3] = 0x0101

  ubData[4] = 0x0008

  ubData[5] = 0x0000

  ubData[6] = 0x0000

  ubData[7] = 0x0000

Running through the routine I do see that I end up for MDL and MDH the following:

  For MDL.word.HI_WORD: 0xFF82

  For MDL.word.LOW_WORD: 0x0801

  For MDH.word.HI_WORD: 0x0800

  For MDH.word.LOW_WORD: 0x0000

When I Scope it in CANape I see: 0xFF82080108000000.  But, where is the other data?  Also, trying to make a connection in CANape with this I can never successfully connect.  Do you see in this example anything I am missing?

Regards,

JFin

JFin said:

        Box.MDL.all = (((uint32_t)pstObj->ubData[0]& 0xFF) << 24) |
                                  (((uint32_t)pstObj->ubData[1]& 0xFF) << 16) |
                                  (((uint32_t)pstObj->ubData[2]& 0xFF) << 8) |
                                 ((uint32_t)pstObj->ubData[3]& 0xFF);

JFin said:

  ubData[0] = 0x04FF
  ubData[1] = 0x0882
  ubData[2] = 0x0008

expresssion (pstObj->ubData[IDX] 0xff) << SHIFT will cut off high byte from the each word.

So, you should code (high / low order of the words is up to you):

Box.MDL.all = ((uint32_t)pstObj->ubData[1]) << 16) | (uint32_t)pstObj->ubData[0];
Box.MDH.all = ((uint32_t)pstObj->ubData[3]) << 16) | (uint32_t)pstObj->ubData[2];

I have tried this before, but the issue I had was by doing this, the message detected by CANape is now:  0x7D05154E02C48A09.  That is nowhere close to the original message that was to go out so I abandoned that method and ended up with what I had.  Even if you shift the order around you will still end up with a messed up message.

Try to inspect eCAN MBOX's MDL and MDH values before calling CANReleaseObj(). If they as you expected, than try to find other MBOX with MDL/MDH close to values that CANape detected: 0x7D05154E and 0x02C48A09. With a small chunk of code it's not so easy to get where those comes from.

What is the value of pstObj->uwLength? 8?

Yes, pstObj->uwLength is 8.

What I am seeing for MDL before calling CANReleaseObj() is: 0xFF01154E.  For MDH the value is still:  0x02C48A09.  This is the only MBOX I have loaded at this point.

The reason that I wrote the function as I had it was because I had a much closer match than going about it the way you have mentioned.  Either way will still not give a proper response to open CANape to begin logging.  I have to use CANalyzer to be able to see the messages flowing unless I use CANape with another device on the CAN bus.

pcdesc->port.pMbxs[ubObjNr].MDH.all

Is the pMbxs volatile pointer to EcanxMboxes structure?

JFin said:

The reason that I wrote the function as I had it was

Does your code with mentioned changes looks like:

void CANConfigMsgObj(can_description_t *pcdesc, uint8_t ubObjNr, TCAN_SWObj *pstObj)
{
    struct ECAN_REGS Shadow;
    union LAM_REGS LAM;
    struct MBOX Box;

    CANRequestMsgObj(pcdesc, ubObjNr);                                      /* get CPU control of the mailbox */

    Box.MSGID.all = 0;
    Box.MSGID.bit.STDMSGID = pstObj->ulMSGID;
    pcdesc->port.pMbxs[ubObjNr].MSGID.all = Box.MSGID.all;
    LAM.LAM[ubObjNr].all = 0;
    pcdesc->port.pLAM->LAM[ubObjNr].all = LAM.LAM[ubObjNr].all;
    if (pstObj->fTransmit)
    {
        Box.MSGCTRL.bit.DLC = pstObj->uwLength; 
        Box.MSGCTRL.bit.RTR = 0;
        Box.MSGCTRL.bit.TPL = (ubObjNr & 0x1F);
        pcdesc->port.pMbxs[ubObjNr].MSGCTRL.all = Box.MSGCTRL.all;
        Shadow.CANMD.all = pcdesc->port.pPort->CANMD.all;
        Shadow.CANMD.all &= ~(1 << ubObjNr);
        pcdesc->port.pPort->CANMD.all = Shadow.CANMD.all; 

        Box.MDL.all = ((uint32_t)pstObj->ubData[1]) << 16) | (uint32_t)pstObj->ubData[0];
        pcdesc->port.pMbxs[ubObjNr].MDL.all = Box.MDL.all;

        Box.MDH.all = ((uint32_t)pstObj->ubData[3]) << 16) | (uint32_t)pstObj->ubData[2];
        pcdesc->port.pMbxs[ubObjNr].MDH.all = Box.MDH.all;

    }
    CANReleaseObj(pcdesc, ubObjNr);
}

Have you tried to set explicitly long value to the MDL/MDH to test, like:

pcdesc->port.pMbxs[ubObjNr].MDH.all = 0xAA550055L

I think I found the problem with the message structure.  Yes, the long does have to be forced it appears... but also with how the TI 320F28335 stores the values.  When I had ubData[0] thru [7] the component seems to only store the 8-byte message inside the first 4 so the other set of 4 is going to waste.  Once the long value was hard set that showed.

The message does appear to come out correctly now when I analyze it with the Vector CANalyzer.  But, even with the message looking good now I still cannot get CANape to connect.  What is the trick to keep it active?

Your routine CANConfigMsgObj() just configure Mailbox and sets the MDL/MDH values. How do you tell CAN core to send the message? Do you disable Mailbox via CANME reg before configuring? Do you enable it after? And then set transmission request bit in CANTRS and wait for acknowledge CANTA bit?

Usual flow when you're going to use one mailbox for different Message ID:

1. Disable Mailbox via CANME
2. Set Mailbox transmit or receive function via CANMD
3. Configure Mailbox sending buffer size via MSGCTRL (if applicable)
4. Set Mailbox MSGID
5. Enable Mailbox via CANME
----
6.a To send data fill the MDL/MDH and set CANTRS bit
7.a Wait for appropriate transmit acknowledge CANTA bit.
8.a Clear CANTA bit by writing just only this bit to CANTA.
----
6.b To receive data check CANRMP bit
7.b Copy or process MDL/MDH fields
7.b Clear CANRMP bit by writing just only required bit to CANRMP

Here is a sample of CAN usage.