• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 310 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.

CAN Error Interrupt

Robert Adsett
Guru 27665 points

I think this a documentation clarity issue (although I may have missed a point in the documentation).

The CAN peripheral appears to have three sources of interrupt, status change, error and recieve/transmit.

If the interrupt is a status change or a receive/transmit interrupt it is indicated in the interrupt register (CANINT).

Status change interrupts are acknowledge by reading the CAN status register, recieve interrupts are acknowledged by reading the message and transmit interrupta are acknowledged by an explicit clear (which the TIVA documentation sayas should not be necessary if the usual interrupt action is taken but I don't see any 'usual interrupt action' that would clear it implicitly).

That only leaves the error interrupt which has no obvious way to clear or recognize.  What I suspect  is that the error interrupt is misnamed and the bit is not enabling a separate interrupt as the data sheet (TM4C120E6) claims but is enabling the status interrupt for a subset of sources.  Since that is not the way it is written though I think it needs to be clarified.

 

Robert

  • 0
    Guru 27665 points

    Sorry that's a TM4C1230E6.

     

    There appears to be no method to edit these posts, I'll just leave the remaining typos unmarked and grind a layer off of my enamel.

     

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Robert Adsett said:
    There appears to be no method to edit these posts

    If you have "signed in" to the forum - the following should reveal - at the bottom of your past post:

    That green pen/pencil indeed enables editing - but only if you originated that post...  (enamel grinding managed elsewhere - suspect a new symbol, targeting that effort, "in the works...")

    Believe that you've done a good job of CAN review.  If you've not yet - "can.c" w/in driverlib provides the greatest detail to unlock CAN mysteries.  (and it does id several error sources - but as you state - little guidance for "error" int. clearance)

  • 0 in reply to cb1_mobile
    Guru 27665 points

    Aha, an obscure icon I missed. Thanks.

    Yeah, I'm using the can.c driverlib for the basic access and I have looked at the example CAN programs (which definitely do have bugs) but neither have been any help in clearing up the issue.  The driverlib functions are what is documented in the TIVA documentation I referred to.

    I am continuing based on the understanding I've noted but I have learned through past experience that when vendor's documentation appears incomplete 80% of the time the obvious interpretation is correct.  The other 20% can lead to a lot of wasted time.  There's an additional smattering of cases where the vendor's documentation appears quite clear but means something different than what you read.  Those can be real time sinks.

    Robert