CAN Interrupts not being tripped K64F

[nhinshaw]

Hey, I am working on a project involving a K64F board with a can transceiver attached on a breadboard.  If i hook up my logic analyzer to the RX line, i can see traffic; however when i wire the transceiver into the k64f, the interrupts created by processor expert using PTB19 for Rx and PTB18 for Tx never seem to fire.  as a result, the board seems to not be getting any of the information. Any help would be appreciated, attached is a picture of my processor expert configuration as well as the project

Original Attachment has been moved to: project.zip

[nhinshaw]

got in this morning and did some messing with the clock on the k64f.  Switched over to the external reference clock and set it at 120 mhz.  verified 250k baud by hooking async serial up to my oscope sending 0xAA over the line.  saw 4 microseconds per pulse, calculated to 250k.  hooked back in CAN, it worked.  Thanks for the help Earl, really appreciate it.

[egoodii]

Success is the final goal!  And thank YOU for 'sticking with' me on this!  I know we ended up 'far afield' from 'No Interrupts', but CAN is like that --- unless the entire CAN communication link is 'near perfect' data interchange won't happen, and the 'fully smart' CAN peripherals only give 'success' interrupts when it ALL works!

[nhinshaw]

Your estimate of .5 ms seems to fall in line with the traffic generated by the other nodes on the line.  This is shown in the attached image from the "good traffic" that i am expecting from my K64F.  The clock appears to be cycling off of the intended rate.  I have it set at 37.5 khz, with an even 12 khz divider for the CAN, leading to what processor expert lists as 250k, however my async serial also says 250k, while being off.  I suspect there is an issue in there with the clock rate being off

is there a register to see what is actually set?

[egoodii · Accepted solution]

I'm not quite sure what to make of your clock numbers, but they make me believe that you are trying to use an on-chip self-oscillator rather than a crystal?  CAN requires 'more like .01%' clock tolerance, and even tighter 'overall jitter', and MUST be run, preferably 'directly', from a crystal source.  I use 8Mhz crystals in my devices, PLLed for the CPU, but selected DIRECTLY as 8MHz clock into the CAN dividers -- as in /2, and 16Tq for 250KHz.

To verify your clock source, you can try to set the internal clock directly out onto the so-named pin, OR what I do is set an FTM block [or UART0 sending continuous 0x55 on N,8,1] -- both can be driven directly by BusClock -- with simple divisors to an output pin and use the pulse-width/frequency there to work backwards to an exact clock rate.

[nhinshaw]

I feel as though i dont fully understand what you are saying.  I do know that there is proper ACKing coming from one of the other devices on the line.  in this case, its the Source address "DE" from the pcan view.  From the end of the k64f, it wouldnt clear to send.  the TX clear interrupt would only clear if i put the k64f in loop mode.  So from the end of the board, it does not think it is clear to send, and it also does not think it is receiving any information.  Does this answer the question better?

[egoodii]

Not exactly.  The CAN peripheral will continuously re-send any packet that it fails to detect a returned ACK (or for which somebody sends a NAK).  So if the TX 'packet out' can be seen on your logic-analyzer, from this node (ahead of the transceiver, of course) exactly once, then the CAN peripheral IS seeing such an ACK (a tiny pulse on RX right at the end of the packet) and we can thus assume the 'basic interconnect hardware' thru TX and RX is working 'at least well enough'.  And I would have to believe a poll of the TX MB SHOULD show 'sent' and give you a timestamp.

So if you disconnect the transceiver from your overall bus, you should see this continuous resend of the first test packet, and if that quits as soon as you hook the bus back up you can be SURE the peripheral is 'happy'!

[nhinshaw]

So i've spent most of the morning attempting to get a good test done.  The TX line from the k64f actually seems to produce garbage CAN information.  Attached is a picture of what I see on my logic analyzer, showing the incorrect extended frame data, as well as "ERROR" for the data bytes.  It is odd that the RX line from the transceiver is picking up the data from the TX line.  I am unsure as to what is going on.  It is of note that if i plug the line into the active CAN line, I do see the normal traffic from the controller, however it is overlapped in some places with this garbage data, as though it is failing to write, and then echoing its TX over the RX

[egoodii]

CAN is inherently half-duplex, so 'self reception' is actually 'good proof' that your TX gets to a terminated wire-pair and your RX picks it up (unless your transceiver is in some kind of local-loopback mode?).  BUT I would LIKE to see just a 'little extra' stuff on RX at the 'end' to be the ACK or NAK from other bus participants.  I am a little concerned about your packet-length though -- I always figure CAN as 'about' 120bits, including 64data, 40-some for header&CRC, plus necessary 'bit stuffing' based on content -- but still at 4us/bit that seems like it should come to about 0.5ms  --  your 0.62 just 'seems long'.  Can you confirm your clock-source/divider?

[egoodii]

Can we assume that your breadboard-transceiver is tied to an otherwise 'known functional' CAN network?  That is, to a wire-pair with proper resistive differential-collapse (termination) AND a fully operational second node at exactly the same bit rate to be in a position to perfectly-receive the packet and supply an acknowledge back to this test board so that TX can BE considered complete and thus generate said interrupt?"

[nhinshaw]

Yes, the system is functional, I was able to pick up traffic with a similar setup on a ke06z, however it has the can transceiver built into it.  on that project, i was able to get the interrupts to trip on the CAN0 line.  attached is a verification of can traffic from my pcan dongle

[egoodii]

Okey-Dokey!  So much for the obvious hardware questions...

When you go to send a packet from the test-unit, does it go out 'once' (as in, acknowledged and so detected via RX)?  That would tell us if the CONTROLLER is 'happy enough', then we could worry about chip config...

I hate to believe the 'new transceiver' would be 'different enough in speed' to require 'new' optimization of the CAN sample-point parameters -- can you run 'everything slow' for first tests?

[nhinshaw]

The line is locked at 250kbit from other hardware on the line.  No good way to change the can speed across the other boards on the line.  The issue in this case is less about writing to the line, the RX interrupt is also not being triggered.  if i attempt to use TX, i also have no interrupt trigger to say the line is clear.  RX picks up no traffic, but the logic analyzer does see the traffic coming to the board.  when i go to send, the data is clear from the transceiver, it just has no interrupt from the micro, or any indication that it got any message.

[egoodii]

You didn't exactly answer my question.  I'm trying to see if the CAN peripheral is 'fully happy' with send (and an ACK receive), proving valid hardware-layer interconnect.  If IT thinks it can send, and you just don't get the INTERRUPT, then we can talk about vector addresses for the part in particular (since they change for just about every part!), and NVIC controls thereto.  Which also begs the question of if such send is good, I might assume you can at least poll the TX MB as 'clear'.