• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 588 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.

CCS/F28M35H52C: Bug in CAN Loopback example

Calvin Taylor25
Prodigy 170 points

Part Number: F28M35H52C

Tool/software: Code Composer Studio

Hey guys,

There appears to be a bug in the can_loopback example. I'm looking at the example found in device_support\f28m35x\v220\F28M35x_examples_Master\can_loopback\m3.

In the function CANIntHandler(), the interrupt register is read. If the returned value is 0x8000, the function sets an error. However, according to the chip documentation, 0x8000 indicates that there _isn't_ an error.

Can you confirm?

Thanks,

Calvin

  • 0
    TI__Guru* 95315 points
    0x8000 indicates Error and Status Register value is not 0x07. This indicates the possibility of the LEC being 0 thru 6. The comments only allude to the possibility of an error. To keep the example simple, it does not investigate further but sets the flag to indicate "some errors may have occurred".
  • 0 in reply to Hareesh Janakiraman
    Prodigy 170 points

    Hi Hareesh,

    Yeah, it took me a while to figure out what was going on. Mostly, because the can.c driver unnecessarily obfuscates register accesses to the CAN block. Specifically,

    CANIntStatus() called with:

    • interrupt status reg=0 actually reads register 0x10
    • interrupt status reg=1 actually reads register 0xB0

    The virtually identical CANStatusGet() called with

    • status reg=0 actually reads register 0x4
    • status reg=1 actually reads register 0x88
    • status reg=2 actually reads register 0x9C
    • status reg=3 actually reads register 0xC4

    The g_bErrFlag looks like it should be an error flag. It's called "ErrFlag." But, as you point out, the comment says that may indicate an error. It may not. There is no explanation for the variable except that it might or might not indicate something. Simplicity doesn't help if it increases confusion.

    Because of the way the interrupt handler is written, it takes three calls to the ISR to service one CAN bus packet. It isn't necessary to do this. In most cases, it isn't advisable to do this. The fact that multiple calls are made isn't mentioned, even though this gets into the fundamentals of how the CAN block functions.

    So, yes, you're right--there is no bug. My bug was caused by receive packets overwriting the previous packet under certain conditions--partly a problem with my code, partly a problem with limitations in the CAN hardware block. It took me most of yesterday to find it because of obfuscated driver code and an example that doesn't do a very good job of explicating the block. That is something you guys could improve.

    Calvin

  • 0 in reply to Calvin Taylor25
    TI__Guru* 95315 points
    Calvin,
    I apologize for the confusion. I will feed this back to the software team.