UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
230 Views
Registered: ‎09-10-2018

CANFD V2.0 IP - Core goes wild at any bus activity - Zynq7000

Jump to solution

So I am trying to integrate the new CANFD V2.0 IP core into my design, and I'm having trouble with the core doing weird things if there is any activity at all on the bus.

I have a fairly simple block diagram, basically a Zynq-7000 processing system (no DDR) connected to the CANFD IP Core. As the core requires two clocks, can_clk and can_clk_x2, I have a clocking wizard generating can_clk=40MHz and can_clk_x2=80MHz from the 100MHz FCLK_CLK0:

block_diagram.png

I then use the xcanfd.h library provided with the generated board support package in the SDK. I'm able to run the interrupt example successfully, i.e. internal loop-back mode within the IP core seems to work fine.

However, when trying to interface my external CANFD PHY with the core out of loopback mode and in normal mode things get weird. I added the CANFD core's TX and RX signals to debug to illustrate my point.

At first, after the CANFD has been initialized and the self-test (using drivers from xcanfd.h) passed, the TX and RX signals rest at a logic 3.3V high signal, as they should:

txrx_pre_send.PNG

However, as soon as there is any activity on the bus, the core starts switching both tx and rx signals real fast, freaking out every other device on the bus:

txrx_post_send.PNG

This doesn't seem to trigger any of the cores interrupts, including the error ones. Interrupts do work though.

I should mention that this is pretty much the first time I do a Zynq-7000 design, and I have little experience with the Vivado Design suite.

However, if anyone has any ideas on where I should start debugging this, that would be greatly appreciated!

A few key details on my design:

  • Custom board. CANFD circuitry have been confirmed on other, non Zynq, boards though.
  • Bus is properly terminated at both ends.
  • I use a PEAK Systems PCANFD device from my computer to the board.

If any other details are necessary, please let me know and I'll provide them.

Thanks,

Nikolai

0 Kudos
1 Solution

Accepted Solutions
Contributor
Contributor
65 Views
Registered: ‎09-10-2018

Re: CANFD V2.0 IP - Core goes wild at any bus activity - Zynq7000

Jump to solution

Turns out this is a case of "It's not a bug, it's a feature".

What we see in my chip-scope screenshot is the CAN-Controller re-sending the message indefinetely due to a bit-error. The reason it looks like an uniform square wave is due to the sampling frequency of the debugging core. With a faster logic analyzer, a CAN-frame is more clearly visible.

The bit-error came from the fact that my external PHY has 120ns of TX/RX loop-delay. As the CAN controller expects to see the data it sends on the RX line (to determine if it has won bus-arbitration), the 120ns delay has to be compensated for. The C standalone driver has a function for that.

In the end I figured that I wouldn't have had these questions if I had a solid understanding of the CAN-protocol, and I would strongly recommend understanding a protocol before trying to implement it.

0 Kudos
2 Replies
Voyager
Voyager
179 Views
Registered: ‎02-01-2013

Re: CANFD V2.0 IP - Core goes wild at any bus activity - Zynq7000

Jump to solution

 

We've been using CAN-FD IP (v1.0) in a Zynq MPSoC design for almost 2 years now. One CAN-FD driver (Petalinux ?) provided by Xilinx has been broken for a while now--from 17.2 through 18.2. We touched-up the driver ourselves to get the IP working, but we're still working with Xilinx to get a fixed version released.

If you're having trouble communicating on an otherwise operational CAN-FD bus with your design, you might want to check the settings being put into the CAN-FD timing control registers by the driver you're using.

Also, be sure the CAN-FD parameters you're using in your Zynq are exactly the same as the ones used by the other nodes on the bus.

-Joe G.

 

Contributor
Contributor
66 Views
Registered: ‎09-10-2018

Re: CANFD V2.0 IP - Core goes wild at any bus activity - Zynq7000

Jump to solution

Turns out this is a case of "It's not a bug, it's a feature".

What we see in my chip-scope screenshot is the CAN-Controller re-sending the message indefinetely due to a bit-error. The reason it looks like an uniform square wave is due to the sampling frequency of the debugging core. With a faster logic analyzer, a CAN-frame is more clearly visible.

The bit-error came from the fact that my external PHY has 120ns of TX/RX loop-delay. As the CAN controller expects to see the data it sends on the RX line (to determine if it has won bus-arbitration), the 120ns delay has to be compensated for. The C standalone driver has a function for that.

In the end I figured that I wouldn't have had these questions if I had a solid understanding of the CAN-protocol, and I would strongly recommend understanding a protocol before trying to implement it.

0 Kudos