PROCESSOR-SDK-AM335X: CAN0 issue

Hi,

What software are you using? Can you post the CAN0 related part of the schematic?

I was using my own communications software, but to eliminate any possibilities of software issues I switched to using cansend and saw the same behavior.

cansend can0 123#DEADBEEF

I've attached a link schematic for the CAN transceiver. See U47.

Thanks,

Tom

And where do you see these oscillations? Can you also post the CAN connections on the processor side?

The oscillation is on the processor's can tx line. It only occurs with the transceiver connected though.

On the processor side, there's really not anything to show as the tx/rx lines go straight to pins J18/K15. They are configured as follows:

0x120 ( PIN_INPUT_PULLUP | MUX_MODE1 ) /* (K15) gmii1_txd2.dcan0_rx */
0x11c ( PIN_OUTPUT_PULLUP | MUX_MODE1 ) /* (J18) gmii1_txd3.dcan0_tx */

Tom

This is extremely strange. I have never seen or heard of such an issue. Have you checked that the pinmux is not getting overwritten by some other entry later in the code? Is your VDDSHV5 power rail at 3.3V?

I had considered that. I have been unable to find any pin definitions stepping on this configuration. I'm using the yocto build environment and in the past it has kicked out a build error when it found conflicting pin assignments. I haven't completely ruled it out yet though.

VDDSHV5 is at 3.3V. I should also add that AM335x itself is on a SOM produced by Phytec. I replaced it and I can still send only one can frame.

Tom

Here is their Bosch/D_CAN device tree info. in case anything in here is helpful:

git.phytec.de/.../c_can.txt

Routing d_can1 over to the mmc pins and enabling has revealed that it behaves the same way as d_can0. The last time I've done testing that worked with can was with an older bsp release, like 15.x. I do remember that in the older release that the TI high end can controller was enabled. In this one, that is disabled and the Bosch can drivers are enabled. I believe TI shows a configuration example which confirms that. This is my can driver configuration:
#
CAN Device Drivers
#
CONFIG_CAN_VCAN is not set
CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=y
CONFIG_CAN_CALC_BITTIMING=y
CONFIG_CAN_LEDS is not set
CONFIG_CAN_TI_HECC is not set
CONFIG_CAN_FLEXCAN is not set
CONFIG_CAN_GRCAN is not set
CONFIG_CAN_RCAR is not set
CONFIG_CAN_SJA1000 is not set
CONFIG_CAN_C_CAN=y
CONFIG_CAN_C_CAN_PLATFORM=y
CONFIG_CAN_M_CAN is not set
CONFIG_CAN_CC770 is not set

Hi Biser,

We have found that the root cause of the communications problems was a problem with the termination resistor connection on the sensor side of the bus, combined with additional bus capacitance on the bus itself due to board layout. However the original problem of oscillation can still not be explained and goes back to the can controller on the AM335x. At the low baud rate, 125k, a bus off conditions occurs as expected. At the higher baud rate no bus-off condition occurs and the can controller tx line continues to pulse at 19 kHz. The only indicator of a faulty state is no response from the devices on the bus. 

I will bring this to the attention of Phytec as well.

Thanks,

Tom

I can only repeat that I have never seen or heard of such an issue on any Sitara device. Can you post a screenshot of the oscillating signal?

Sure, here it is. Yellow is Tx, blue is Rx. When the termination resistor is present, the bus will recover from a bad connection and a can bus passive error is detected. At 125k the bus off error occurs instead. I would expect bus-off at 500k as well, but maybe there is something I am misunderstanding with regards to can error handling.

Thanks,

Tom

Some questions on this scope capture:

Is the 19Khz waveform you are capturing happening with or without traffic?
Does the 19KHz waveform happen on the TI EVM?

Hi Biser,

I have a Phytec AM335X dev kit, but have not yet tried to reproduce this on that board, I will need to switch to an older dev. branch and recompile the kernel to do so. There is no other traffic on the bus, only one device and this signal appears after sending a single message at 500k, regardless of whether the device is connected.

I have also been discussing this with Phytec and they don't have an explanation for it. I will see if this is reproducible on the eval kit when I'm able to block off some time and let you know what I see there. 

Thanks,

Tom