How to enable dcan2

Hi Shawn,

can you check if you can find something usefull in those wikies:
processors.wiki.ti.com/.../DRA7xx_GLSDK_DCAN_Driver
processors.wiki.ti.com/.../Linux_Core_DCAN_User's_Guide

Regards,
Yordan

Hi Shawn,

Can you please dump registers 0x4A00 3688 and 0x4A00 368C? That are the padconf registers for the 2 pins.

Meanwhile one remark. It is not causing the issue, but take into account that TX pullup is useless.
RX pullup is also useless but could be useful for debug if CAN transceiver chip is introducing glitches for ex. during reset.

Hi Yordan,
thanks for the reply.
Since the default status of dcan2 is "disabled",
so I think I need some instructions about modifying the device tree.

I also tried to use dcan2 on dra7 evm board(jamr3) by using the modifications above. Nothing comes out at jp3.
The schematic shows dcan2 connected to mux and it selects i2c3 as default output. It also says software can't control the mux of dcan2 and i2c3, it needs to change resistance.
Therefore I just checked pin4 of RU113, which I think it's the dcan2 tx, still nothing.

Is there anything wrong about my modification?
Thanks for your time.

Hi Stanislav,
thanks for the reply,
I will try and let you know later.
Have you try dcan2 on dra7 evm board with GLSDK_7.04.00.03 and make it work?
If so, what's the exact change need to be done?

Hi Stanislav,

root@dra7xx-evm:~# omapconf read 0x4A003688

00020002

omapconf: powerdm_deinit(): cpu not supported!!!

omapconf: clockdm_deinit(): cpu not supported!!!

root@dra7xx-evm:~# omapconf read 0x4A00368C

00020002

omapconf: powerdm_deinit(): cpu not supported!!!

omapconf: clockdm_deinit(): cpu not supported!!!

Hi,

I think the mode of the pins is correct, right?

Is there anything i can do for you to provide more information?

Now I just want to enable dcan2 on dra7xx evm board with GLSDK_7.04.00.03.

processors.wiki.ti.com/.../DRA7xx_GLSDK_DCAN_Driver
processors.wiki.ti.com/.../Linux_Core_DCAN_User's_Guide

Dcan1 works well as i following the instructions of above links,

but dcan2 keeps no signal.

Please kindly give me some directions,

thank you so much.

Hi Shawn,

Yes, muxmode looks correct. And since you are measuring behind the PCB muxes, it should not be a muxing problem.

I don't know. I would suggest you to check the following thread:

Hi Stanislav,

Thanks for the reply.

That thread is asking about dcan1 connecting to dcan2,
and no answer is verified.
but we didn't do that,
dcan1 works fine when we connect it to PC with a can/usb converter.
We can receive and send message with PC's can simulation program.

The other question in that thread is asking about /dev/can* is missing...
but we can see can0 and can1 when we type "ifconfig -a".
I think "can*" will not appear in /dev.

The problem is dcan2 output nothing, keeping a high state.
Would you mind helping us to find someone who has verified dcan2's functionality on dra7xx evm with GLSDK_7.04.00.03?
Thank you so much.

Hi Shawn,

I have recently used the same DCAN2 pins (jp3) on DRA7xx-evm REV H to do a test over UART10.

So the steps essentially remain same except for pinmux, instead of uart10 you'll need to choose dcan2_rx/tx

Summarizing the steps to be done
1. Set muxmode of GPIO6_14 and 15 to uart10_rx/tx - mode 3, dcan2_rx/tx input enabled and pull-up
2. Enable uart10 dcan2 node in EVM dts file (add uart10 dcan2 node, set status to okay)
2. Remove pull-down resistor R265 (10K Ohm) on sel_i2c3_can2 line and move it to R264 (pull-up) - On one board, I just removed R265 and it worked but better to add the pull-up as described in the schematics document 
3. After kernel boot up, in order to select dcan2 (SEL_I2C3_CAN2), Set the PCF8575 line state to output High by writing to pcf_gpio21 - pin #3 (on one board I had to change pin #11 so it's better to set both pin#3 and 11) by command shown below 
i2cset -f -y 0x0 0x21 0xff 0xeb ({dont read back})

Follow this and

also make sure to add a print in dcan driver probe() at the end to see if probed successfully.

In kernel at the prompt, try reading any dcan2 module registers using "omapconf" to see if the clocks are enabled as expected (you may need to open the /dev/<can> file to ensure the device is kept on an dthe clocks are running) or use an IOCTL to read if one's available.

you may use a voltmeter or a scope and read the data on JP3, to verify,

In my test I connected two dra75x evms back to back over UART and was able to transfer data successfully.

Regards,

RK

Shawn,
I was able to toggle the TX pin (1/0) by using the embedded GPIO function of DCAN2.
It is in the DCAN_TIOC register (0x4848 01E0). Setting LSB to 0x6 sets TX to 1. Setting to 0x4 clears TX to 0.
Just wanted to let you know because this may help you to debug.

But most importantly see if dts file is configured and try reading DCAN2 registers as Ravikumar suggested.

Shawn,

"Therefore I just checked pin4 of RU113, which I think it's the dcan2 tx, still nothing."
You are sending packets in a endless loop and measuring pin 4 with a scope, and pin is always stays high. Is my understanding correct?

Additionally, DCAN has several loop-back modes for tests. They are described in 24.10.4.12.3 Test Modes of TRM chapter DCAN.

Hi Ravikumar,

thanks for the reply,

as you can see my original modification is as below:

&dra7_pmx_core {

 dcan2_pins_default: dcan2_pins_default {

   pinctrl-single,pins = <

     0x288 (PIN_OUTPUT_PULLUP | MUX_MODE2) /* gpio6_14.dcan2_tx */

     0x28C (PULL_UP | MUX_MODE2) /* gpio6_15.dcan2_rx */

   >;

 };

 dcan2_pins_sleep: dcan2_pins_sleep {

   pinctrl-single,pins = <

     0x288 (MUX_MODE15 | PULL_UP) /* gpio6_14.off */

     0x28C (MUX_MODE15 | PULL_UP) /* gpio6_15.off */

   >;

 };

};

&dcan2 {

 status = "okay";

 pinctrl-names = "default", "sleep";

 pinctrl-0 = <&dcan2_pins_default>;

 pinctrl-1 = <&dcan2_pins_sleep>;

};

The red line is copied from dcan1 pin setting.

I add input enable and pull up as you suggested as follows:

0x288 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpio6_14.dcan2_tx */
0x28C (PIN_INPUT_PULLUP | MUX_MODE2) /* gpio6_15.dcan2_rx */

After this, there is something on pin4 of RU113, but not like dcan1.

When i use cansend to send data on dcan1, dcan1 tx and rx keeps generating data until i use canconfig stop.

But cansend on dcan2, only dcan2 tx has data generated and keeps a very short time, then it backs to high state,

if I use cansend command againg,  nothing comes out,

I have to stop, config, start again to use cansend and tx generate data for a very short time.

Here is the command for dcan1:

canconfig can0 stop
canconfig can0 bitrate 50000 ctrlmode triple-sampling on
canconfig can0 start
cansend can0 -i 0x800 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 -e

Here is the command for dcan2:

canconfig can1 stop
canconfig can1 bitrate 50000 ctrlmode triple-sampling on
canconfig can1 start
cansend can1 -i 0x800 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 -e

My questions now are:

1. Why the pins of dcan2 need to set input enable not like the setting of dcan1?

2. Do you have any idea about dcan2 tx generating a short period of data and rx keeps nothing?

3. Would you mind...spend a little time to config dcan2 on your dra7xx evm board and verify its function?

Thanks for your big support.

Hi, Stanislav,
I don't send packets in an endless loop,
I use a scope setting high to low edge trigger to measure pin4, and it is always high.

I use the command below to send data:
canconfig can1 stop
canconfig can1 bitrate 50000 ctrlmode triple-sampling on
canconfig can1 start
cansend can1 -i 0x800 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 -e

I use the same commands for dcan1 except changing can1 to can0,
dcan1 tx rx keeps generating data until i send canconfig can0 stop again.
So i suppose dcan2 should keep generating data too.

I will try to read out all the registers value for you to see if anything is wrong.

Thanks for your help.

Hi Shawn,
There is one important difference between DCAN1 and DCAN2 on this board. DCAN1 has its own CAN driver chip on-board. But DCAN2 has only pins TX and RX on a connector. User can (and should) connect his own CAN driver chip.
I guess DCAN driver (software driver) expects to see on RX same packets as on TX. It is because if driver chip and bus is ok, TX packets should be visible on RX pin. If not, I presume that SW driver gives up.
You can either connect a CAN driver, or try short-circuiting TX with RX.

To my understanding, you didn't do so. Sorry if I missed something.

Regards,
Stan

Hi Shawn,

it's great that you resolved the issue and thanks for sharing the details. I will close the thread, but if you face any problem you can write here and reopen it.

Regards,
Yordan