• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 740 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28377D: CPU2 CANA occasional missed message

Stephen Bialkowski
Intellectual 450 points
Part Number: TMS320F28377D

Hello,

I have CPU2 handling CANA IO on a 1MHz high-precision clock.  I am working on a 2016 Mac Workbook that hosts a windows 10 install on top of Parallels.  

To test communications,  I am using a PCASN-USB Pro and PCAN-Viewer.  I have PCAN-Viewer send one message every 1ms.  I have registered 16 CAN objects (8 rx, 8 tx).  Of which I am only using 2.  The PC to C2000 message ID is 0x02000002.  The response message ID is 0x01000000.  

Here's the issue I am wondering about: I find the occasional missed message (2-6 in order 10^5 messages).  What I find strange is, when I put the CAN message reception on an ISR, receive status interrupts, and accumulate them, I get a status interrupt for every inbound message, however, I don't get an interrupt for the message object receiving data.  I believe it's reasonable to rule out the test as the source of the error because the receive status interrupt is always consistent with the number of messages sent by the test HW/SW.  Under what circumstances could I get the status interrupt, but not the message interrupt?

I have tried several things to further characterize the issue:

- query the CAN core for all received messages every time the receive status interrupt occurs.

- disable receive interrupts, and query the CAN core in the main loop.  

- change the transmission rate to 2ms.  

After sending 10^6 messages @ 2ms, I show no lost messages.  So the problem seems related to timing.  In theory, I should be able to send 8K messages per second.  So, The bus should be busy only 25% of the time.  

I hope to gain a better understanding of how this could happen, and how it can be prevented.  Perhaps someone more versed in CAN IO on this target could suggest considerations in this matter.  

Thanks in advanced!

Stephen

  • 0
    TI__Expert 8950 points
    Stephen,

    Interesting problem. Just to clarify, does the message object always receive the data? That is, are you just missing the MO interrupt or does the data get lost too?

    Have you tried assigning the message object interrupt to the other interrupt line via the CAN_INT register?
  • 0 in reply to Adam Haun
    Intellectual 450 points
    Adam,
    I tried reading all valid message objects via polling in the main loop after I discovered the issue using the ISR approach. The results were similar. So, I think that means the data is missing.

    It's also worth noting that there's nothing in the registers or error interrupts to indicate any problem. What's puzzling is the CAN core must know about the "missing messages" on some level due to the receive status interrupt count being higher than the number of messages received.

    It's not clear to me how to route just the message object interrupts to CANA1_INT instead of CANA0_INT. I tried binding CANA1_INT to a second ISR, enabling it in the PIE control regs, and enabling the global can interrupt 1. Nothing invoked the corresponding ISR. Thoughts?

    Thanks again!
    Stephen
  • 0 in reply to Stephen Bialkowski
    TI__Expert 8950 points

    Okay, if the data's not in the message object then changing the interrupt line won't matter. For future reference, you also need to set the relevant bit in the CAN_IP_MUX21 register, and make sure that the enable bit in CAN_GLB_INT_EN is set.

    The rarity of the errors and the dependence on transmission rate makes me suspect a problem with the bus wiring or bit timing configuration. If a bit flips in the message ID field, the module would still receive the message but it wouldn't get stored in a mailbox due to the ID mismatch.

    Since you're sending data from the PCAN, we can probably assume that the transmit bit rate is correct. If you post your oscillator frequency, PLL configuration, and CAN bit timing register value I can check them. Also, make sure both ends of the line are terminated with a 120-ohm resistor. According to its manual, the PCAN doesn't have one built in. Maybe try a different cable too.

  • 0 in reply to Adam Haun
    Intellectual 450 points

    Adam,

    Thanks for the tip on CAN_IP_MUX21.  

    I made a new twisted pair with a 120Ohm resistor on the PCAN end.  I verified 120Ohms at both ends.  Unfortunately, results are consistent.  

    The CAN clock is setup to run at 1Mhz.  The system clock is setup to run at 200MHz.

    Whether the clock is actually running at 1MHz remains a question in my mind.  We ran into a clock problem before.  The EE decided to use an external clock due to known issues with the CAN clock on the TMS320F28377D.  This had appeared to fix the issue.  How this was accomplished is beyond me.  But I will ask if relevant.  

    ClkCfgRegs (CPU1):

    ClkCfgRegs for CPU2 are all 0s.  

    CanaRegs (CPU2):

  • 0 in reply to Adam Haun
    Intellectual 450 points

    Adam.  I don't think the images of the registers posted.  Perhaps this will work...

    ClkCfgRegs (CPU1):

    CanaRegs (CPU2):

  • 0 in reply to Stephen Bialkowski
    TI__Expert 8950 points

    [CORRECTION]

    Sorry, I spoke incorrectly. Your bit clock selection is fine; it's using SYSCLK, which is already sourced from an external oscillator.


    We have an app note and spreadsheet calculator for CAN timing bit settings and oscillator tolerances. It might be helpful:

    www.ti.com/.../sprac35.pdf

    www.ti.com/.../getliterature.tsp

  • 0 in reply to Stephen Bialkowski
    TI__Expert 8950 points
    Your bit timing settings don't look right. If your SYSCLK is 200 MHz, and your BRP is 9+1=10, then the CAN bit clock is 20 MHz. To get 1 Mb/s, you need 20 time quanta per bit. But your Tseg1 + Tseg2 + 1 for the sync segment is only 18. That gives 1.111 Mb/s. Try changing Tseg2 to 5 and see if that helps.
  • 0 in reply to Adam Haun
    Intellectual 450 points
    Adam.
    Thanks for looking at this. Unless I'm reading the TRM wrong, those values should be interpreted as (Tseg1 + 1) + (Tseg2 + 1) + 1 = 20. For the sake of benefit of doubt, I increased Tseg2 by 2. 1MHz nominal bit-rate communications using PCAN fail entirely. Perhaps it's appropriate to verify via scope, and/or write a CANA to CANB test to see if we can rule/single out PCAN as the culprit. Thoughts?

    Thanks!
    Stephen
  • 0 in reply to Stephen Bialkowski
    TI__Expert 8950 points
    Wow, I am really off my game today. Sorry for the confusion! You're right about the register values. I was thinking of I2C bit timings.

    A scope is definitely a good way to verify the bit rate on both ends. Sending a frame from the MCU will let you verify what bit rate it's expecting. I recommend scoping the RX pin on the MCU to start with since it always gives you the actual state of the bus.