• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 1359 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/HALCOGEN: Consistently inaccurate DLC on first received frame of CAN1 in RM46x HDK and overall delay in response.

NeilBerry_at_Parker
Expert 1995 points
Part Number: HALCOGEN

Tool/software: Code Composer Studio

Getting to the point where I have encountered this problem is actually welcome progress, and that is thanks to the valuable responses I have gotten so far.

I am using HalCoGen 4.6.1 to create builds for a RM46 HDK.  I have a USB CAN device to send prepared CAN frames.  The prepared messages can have different lengths (DLC).  In evaluating the response times, I am reading the DLC value and sending a CAN message out with the DLC value.

Reliably, the first DLC value is wrong as shown in IF2MCTL.  It should be either 6 or 8, but it is 7.  I have traces where it should be 8, but 7; and where it should be 6, but is 7.  The DLC in IF2MCTL becomes accurate after the first frame.

Also, there is a 400 ms delay from the device sends the frame and when the return frame indicates the message length.

;$FILEVERSION=1.1
;$STARTTIME=42937.5972109375
;
;   H:\IoT\TI\20170721_CANLogs\WhySeven2nd.trc
;
;   Start time: 7/21/2017 14:19:59.025.0
;   Generated by PCAN-View v4.1.1.463
;
;   Message Number
;   |         Time Offset (ms)
;   |         |        Type
;   |         |        |        ID (hex)
;   |         |        |        |     Data Length
;   |         |        |        |     |   Data Bytes (hex) ...
;   |         |        |        |     |   |
;---+--   ----+----  --+--  ----+---  +  -+ -- -- -- -- -- -- --
     1)      5060.6  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
     2)      5062.0  Rx     00000002  1  07
     3)      5560.6  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
     4)      5562.0  Rx     00000002  1  08
     5)      6060.6  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
     6)      6060.6  Tx     00000001  6  00 74 2D 91 CA F2
     7)      6062.0  Rx     00000002  1  08
     8)      6062.8  Rx     00000002  1  08
     9)      6440.7  Tx     00000001  6  00 74 2D 91 CA F2
    10)      6441.9  Rx     00000002  1  06
    11)      6560.7  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    12)      6562.0  Rx     00000002  1  06
    13)      6940.7  Tx     00000001  6  00 74 2D 91 CA F2
    14)      6942.0  Rx     00000002  1  08
    15)      7060.7  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    16)      7062.0  Rx     00000002  1  06
    17)      7440.7  Tx     00000001  6  00 74 2D 91 CA F2
    18)      7442.0  Rx     00000002  1  08

 

;$FILEVERSION=1.1
;$STARTTIME=42937.5921254167
;
;   H:\IoT\TI\20170721_CANLogs\WhySeven.trc
;
;   Start time: 7/21/2017 14:12:39.636.0
;   Generated by PCAN-View v4.1.1.463
;
;   Message Number
;   |         Time Offset (ms)
;   |         |        Type
;   |         |        |        ID (hex)
;   |         |        |        |     Data Length
;   |         |        |        |     |   Data Bytes (hex) ...
;   |         |        |        |     |   |
;---+--   ----+----  --+--  ----+---  +  -+ -- -- -- -- -- -- --
     1)      2748.3  Tx     00000001  6  00 74 2D 91 CA F2
     2)      2749.5  Rx     00000002  1  07
     3)      3248.3  Tx     00000001  6  00 74 2D 91 CA F2
     4)      3249.6  Rx     00000002  1  06
     5)      3748.3  Tx     00000001  6  00 74 2D 91 CA F2
     6)      3748.3  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
     7)      3749.6  Rx     00000002  1  06
     8)      3750.5  Rx     00000002  1  06
     9)      4112.3  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    10)      4113.7  Rx     00000002  1  08
    11)      4248.3  Tx     00000001  6  00 74 2D 91 CA F2
    12)      4249.6  Rx     00000002  1  08
    13)      4612.4  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    14)      4613.8  Rx     00000002  1  06
    15)      4748.4  Tx     00000001  6  00 74 2D 91 CA F2
    16)      4749.6  Rx     00000002  1  08
    17)      5112.4  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    18)      5113.8  Rx     00000002  1  06
    19)      5612.4  Tx     0CEF900A  8  06 07 00 00 00 00 00 FF
    20)      5613.8  Rx     00000002  1  08

  • 0
    Expert 1995 points
    In a recent retest, the 400ms delay appears to be in waiting for canIsRxMessageArrived to return true/ready.
  • 0 in reply to NeilBerry_at_Parker
    TI__Guru 59540 points
    Hello Neil,

    If you put a scope on the transmit from our tool to the device, can you see if the incoming message is delayed or if it is something related to the receive function on the device? Certainly, a 400ms delay would not be acceptable under most use cases of CAN. What baud rate are you using?

    In regard to the DLC not being accurate, are you receiving all of the data that was transmitted? Are there any CAN error conditions such as CRC error, framing error, or such?
  • 0 in reply to Chuck Davenport
    Expert 1995 points

    The delay appears to happen within the while loop (the code I am using is some found in example_canIntCommunication)

          while(!canIsRxMessageArrived(canREG1, canMESSAGE_BOX1));
          canGetData(canREG1, canMESSAGE_BOX1, rx_ptr); /* copy to RAM */   

    The inaccurate DLC happened when I would read the DLC within canMessageNotification before the while loop.  The DLC was accurate when I started reading the DLC after the while loop.  It is little surprising that accurate values are not ready within canMessageNotification.

    The USB Can tool does not report any problems, but then again if it is the source of the issue it might not.  The scope did not appear highlight any flaws, and showed regular triggering of frames.  It is possible that the USB can tool is some how holding things up.

    I will see what I can determine with the scope.

  • 0 in reply to NeilBerry_at_Parker
    TI__Guru 59540 points
    Hi Neil,

    The function canISRxMessageArrived() is reading and returning the state of the NEWDat bit in the CAN message. This bit will be set when the message object has been updated with new data. It will be interesting to see what you find with the scope relative to timing of the CAN message from start of transmit to completion since MSGBOX will not indicate it has been updated until the message is completely received.
  • 0 in reply to Chuck Davenport
    Expert 1995 points

    At the beginning of this post, I added CAN frame traces which appear to indicate that there was a 400ms delay within the canMessageNotification (or as you suggested a 400ms before that was invoked).

    As a quick test, I created a counter to see how often canIsRxMessageArrived function gets called.  In a test this morning, it was only ever called once per frame received and there was no delay.  The transmit frames were logged at about 1ms.

    I am going mark this as solved.  I do not know for sure whether this is a situation of misdiagnosis or a lucky code change somewhere.

    Current Problem: I am not getting the accurate Message Identifier in my current code, so I would be grateful for any suggestions on how/where to get that value.  The receive Messagebox has a mask of 0x0, so the Message Identifier needs to be somehow collected, just like I have to collect the DLC.