K70 CAN troubles

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K70 CAN troubles

493 Views
robertyork
Contributor II

I'm having troubles with the CAN driver apparently leaving the last message I try to send in the buffer. That may or may not be the case, but that's how it appears.

I have a custom board that is based off a K70 120 Tower board, and I'm using CodeWarrior 10.6, with MQX 4.1, using a cloned TWRK70120 BSP that has been modified for our pin-outs. Clocks and such should all be the same as the Tower board. I'm actually using the MQX4.0.1 CAN driver that I pulled forward, because I was getting some pretty bad halts of a similar nature as below using the MQX4.1 CAN drivers.

Starting out, everything seems to work fine. I use FLEXCAN_Tx_mailbox() and print what I stuffed into the data buffer to the screen, but the last message I send doesn't seem to get out of the chip. It's printed to the screen properly, but the device on the other end of the bus doesn't see that message come through, until I send one more message into the buffer. Then of course, the last message stuffed in there seems to be stuck.

With the MQX 4.1 CAN drivers, trying to send data would simply have the flexcan_send() function kick back with an error and do nothing after sending anywhere from 2-10 messages. Digging in to the driver, it seemed to be waiting on some sort of interrupt, like an ACK or something. Turning on error reporting would just report errors constantly, because the driver doesn't set itself up properly when you enable error reporting (it's a pretty clear bug, to me. I reported it through other channels).

The CAN demo software which has a task running forever sending one CAN message a second seems to work fine, on both versions of the CAN driver. But if I remove that task and send messages on demand (from a button push, for example), I get this behavior. Is there some sort of CAN buffer flush I need to be doing? Is anyone else having any issues of this nature?

I've heard of people recommending the PE driver. Should I be using that instead of the MQX drivers?

Edit: Another piece of information: If I send a message in to this K70 board from my other device, then the 'stuck' message suddenly appears on the other device, like it got pushed out of the buffer on the K70 by the incoming data, somehow. Even if the sent data's ID doesn't match anything the K70 is looking for. It's like the hardware is hung, waiting for something from the other end, which it doesn't get until you force another message in, or it sees data from the other side.

Some more information:

In digging into the MQX 4.1 driver to see if I could get that running again, I narrowed down the halt to the file fsl_flexcan_driver.c, in the function flexcan_send(). It has a wait for event with no timeout. I changed it like this:

        if(result == kFlexCan_OK)

        {

               // Wait for the event

               /* RY: Added 10 tick timeout to gracefully recover from message not getting sent */

               if (_lwevent_wait_ticks(&event, 1 << mb_idx, FALSE, 10) != MQX_OK) {

        printf("\nEvent Wait for send failed\n");

        }

I see that error message I added get thrown to the console at the same times it would halt previously, but now it sends the data out fine. So, aside from spitting this error message and pausing here for a few ticks, it works. Further, sometimes, under constant message sending, this error will just go away, only to return again for a while. This begs two questions:

1. What is it halting on, and why am I not getting the event it's waiting for, at seemingly random times?

2. Why is a driver for an RTOS halting at all? I would have expected it to always have timeouts and other things to guarantee real time performance. Maybe this is a different design style, using multi-tasking where another task monitors the CAN TX and RX tasks to see if they've halted, and somehow kick them back into operation, but that seems overly complicated compared to just not putting blocking waits into your driver to begin with.

0 Kudos
2 Replies

270 Views
Martin_
NXP Employee
NXP Employee

There might be a problem with interrupt flags clearing. It seems it does read-modify-write on FlexCAN interrupt status register (IFLAG1) and so the operations clears all flags that are set in the register, because they are w1c (write 1 to clear) bits.

Try to simply write to the IFLAG1 register the status bit mask you wish to clear (IFLAG1 = tmp_reg vs. IFLAG1 |= tmp_reg).

0 Kudos

270 Views
mjbcswitzerland
Specialist V

Hi Robert

I have neither experience with the MQX nor PE CAN drivers but have attached the one from the uTasker project as reference in case it proves to help in some way.

This has been used in Coldfire and Kinetis FlexCAN projects for about 9 years and I didn't hear of any problems or such effects.

Regards

Mark

Kinetis: µTasker Kinetis support

K70: µTasker Kinetis TWR-K70F120M support / µTasker EMCRAFT K70F120M support

CAN: http://www.utasker.com/docs/uTasker/uTaskerCAN.PDF / FlexCAN.wmv - YouTube

For the complete "out-of-the-box" Kinetis experience and faster time to market

0 Kudos