AnsweredAssumed Answered

K60 CAN InterruptRxTx not working: Buffers not changing back to Empty or Unlocking on Receive, and Interrupt skipping/missing every other one on transmit.

Question asked by Jeff Sylvester on Feb 13, 2015
Latest reply on May 21, 2016 by Dustin Boyette

I have a K60F120 tower and K60N152 tower and am trying to set up can network.  Interrupt mode is not working.  both receive and transmit are tied to the same interrupt line.  I ran codewarrior example code from processor expert library that sends one message out and loops back.  this code performs CAN_SendFrame(), and then does CAN_ReceiveFrame()  sending and receiving one message then ending/quiting.  I modified the code to keep going using simple one second loop to send and receive on one second loop.  and took out loopback and connected regular wires, and also have CAN analyzer connected.  First message works fine, then second and third and fourth, etc.. message fail because Message Buffer is not being properly cleared/reset.  Code jumps to InterruptRxTx Interrupt routine generated by PE tool, that reads the IFLAG1 register, and clears MASK1 register and calls user event either OnFreeTxBuffer or OnFullRxBuffer.   I was having problems so I configured one TWR-K60 as receive only and the other TWR-K60 as transmit only.  on the transmit only one, it actually transmitts the messages ( I have incrementing data message, message1 has data=1, message2 has data=2) but the interrupt does not trigger,  (It skips every other one) this tells me the message buffer is not being cleared / initialized, I can see on the CAN analyzer that the messages are going across the bus, but my code tells me that every other message has failed to transmit, because the interrupt is not being triggered. I see by looking at the registers in the debugger that the IMASK2 and IFLAG2 registers are mirroring the ESR1 register and the IMASK1 registers some how?  Similarly the receive only tower receives the first message fine, the second message gives full so no interrupt happens, the third message does overflow,  which says we are actually seeing the messages but not processing them because the interrupt does not happen to tell me I have a message.  If I touch the IMASK2 or IFLAG2 registers on either one, I get bus fault and the core locks up>  it seems like this interface only designed to operate in polling mode not interrupt mode.  the code initialzes properly then after sending or receiving one message it is toast, because the interrupt never triggers again.  My configuration is the same as field devices, where they typically send mostly data, and another one reads mostly data,  this hardware design where you have to ping pong to read different buffers in order to free up the just transmitted or received buffer seems like a bad design,   once you service the buffer, it should reset.

on the RxBuffer CODE table, it says Servicing a buffer is to either read a different buffer, or read the timer register. and that servicing a FULL buffer does not set it to EMPTY, it just unlocks for new message to overwrite the current message.  and if you service a OVERRUN it goes back to FULL> but then farther down in the manual 48.4.3 Receive Process, it says

Recommended way to Service a mailbox

1 Read the Control and Status Word of Mailbox

2 Check BUSY bit

3 Read Mailbox data

4 Acknowledge IFLAG register of Buffer you are in (the one that cause the interrupt)

5 Read the timer Register. 

 

it looks to me like the example code is not set up correctly because the CAN_SendFrame(), and CAN_ReceiveFrame()  are actually setting and clearing flags, and reading the timer, when you want the interrupt routine to be doing this?   it seems backwards?  all I know is that I cant clear the MB to properly reset and process new data?

Outcomes