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.

TMS320F28379D: Receiving extended and standard IDs.

Part Number: TMS320F28379D

I'm working on a CANopen Lite project for the F28379D and part of it is a simulation/emulation of the Lawicel CANUSB dongle.  So far I have both the CANUSB functionality and I'm working on the Object Dictionary support routines. With the CANUSB monitor it's possible to send messages.  Received messages come in and are identified by either a 'T' or 't' for Extended or Standard respectively.  Unlike the Microchip CAN devices (and others)  that allow masking to enable either or both sizes of IDs it appears the message objects in the F28379D can only receive on or the other.  The problem I'm having is an extended message with a 29 bit ID is showing up in the standard ID message object.  Not sure why.

CANUSB emulation enabled
>t123145  --> proper standard ID with ID=0x123 with 1 byte 0x45.
t23429988 --> improper extended ID which should be 0x12345678 with 2 data bytes 0x99 0x88

It's likely my code or how I've set things up or maybe bit masking.  However before I dig in further is there a way to get one message object to be filled with either size ID?

Thanks

John

?
TMS320F28379D Lawicel CANUSB Emulator
C)lose CAN Port
c)anUSB emulation toggle
e)cho user input toggle
F)lags status
N) Serial Number
O)pen CAN Port
S)et CAN Bitrate 0..8
t)ransmit 11 bit message tiiilnnnn...
T)ransmit 29 bit message teeeeeeeelnnnn...
V)ersion
? -- This help screen
>c
CANUSB emulation disabled
>?

TMS320F28379D Interface Program 1.00a
C)lose CAN Port
c)anUSB emulation toggle
e)cho user input toggle
F)lags CANopenLite status
h)eartbeat CANopenLite enable toggle
O)pen CAN Port
S)et CAN Bitrate 0..8
V)ersion
? -- This help screen
>

  • Never fails.  Post a request for some help and then promptly find the solution.  Like buying a snowblower for the next main snowfall and then it never snows again.

    Anyway, Laptop Screen 1080 resolution makes for small text.  A large function that does testing on the received record, in many places, to decode the information and there just had to be one spot where a spelling mistake (from cut and paste likely) resulted in the code looking at the ID size flag in the Tx record rather than the Rx Record.  Therefore the test below looked at CANMsgTxRec.flags

               if (fCANUSB_Simulate) {
                    if (CANMsgRxRec.flags == CAN_MSG_FRAME_EXT) {
                        PutSerial('T');
                        uIntToHex(CANMsgRxRec.id.lid,8);
                        PutBuffer();
                    }
                    else {
                        PutSerial('t');
                        uIntToHex(CANMsgRxRec.id.sid,3);
                        PutBuffer();
                    }
    Now the code works properly showing both received Extended ID messages and Standard ID messages. 

    T0BFE640022600  Sent from a node FE (client) to Node 64 (server) with command 26
    T0F64FE003260064  Reply from node 64 to Node FE with the data requested by command 26.
    t70180102030405060708  A generic SID message with ID 701, len=8, data 01 02 03 04 05 06 07 08

    This is how I initialized it.

        CAN_setupMessageObject(CANBaseAddress, RX_MSG_EXT_ID, 0,
                               CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_RX, 0,
                               CAN_MSG_OBJ_USE_ID_FILTER, RXMSG_DATA_LENGTH);