This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352: DCAN configuration

Part Number: AM3352

Hi Champs.

#1.

Regarding the DCAN0 / DCAN1, I found those 2 TRM places are not the same.

TRM  page 4808:

The base address for DCAN0 RAM is 0x481C_D000 and DCAN1 RAM is 0x481D_1000.

 

TRM page 183:

 DCAN0 0x481C_C000 0x481C_DFFF 8KB DCAN0 Registers 0x481C_E000 0x481C_FFFF 8KB Reserved

DCAN1 0x481D_0000 0x481D_1FFF 8KB DCAN1 Registers 0x481D_2000 0x481D_3FFF 8KB Reserved             

Why the DCAN0 /DCAN1 has 2 different Base Address?

#2.

Do we have any document to guide us how to set the DCAN 0 / DCAN 1 on the DTSI?

This is the TI official DTSI for DCAN0/1 setting.

dcan0: d_can@481cc000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can0";
reg = <0x481cc000 0x2000
0x44e10644 0x4>;
interrupts = <52>;
status = "disabled";
};
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can1";
reg = <0x481d0000 0x2000
0x44e10644 0x4>;
interrupts = <55>;
status = "disabled";
};

And we found the customer can make the DCAN0/DCAN1 work by this setting, why?

Does the DCAN Phy Vendor needs to provide the DCAN DTSI?

How to set the reg / interrupts / status correctly?

BR Rio

dcan0: can@481cc000 {
compatible = "ti,am3352-d_can";
ti,hwmods = "d_can0";
reg = <0x481cc000 0x2000>;
clocks = <&dcan0_fck>;
clock-names = "fck";
syscon-raminit = <&scm_conf 0x644 0>;
interrupts = <52>;
status = "disabled";
};

dcan1: can@481d0000 {
compatible = "ti,am3352-d_can";
ti,hwmods = "d_can1";
reg = <0x481d0000 0x2000>;
clocks = <&dcan1_fck>;
clock-names = "fck";
syscon-raminit = <&scm_conf 0x644 1>;
interrupts = <55>;
status = "disabled";
};

  • Hi Rio,

    I will check with the TRM maintainer and see why there is the difference. Is the last DTSI the one that is working?

    Best Regards,

    Schuyler

  • Hi Rio,

    I think I understand your question better now.

    The difference that you are pointing out in the TRM is that the message RAM is located higher up in memory from the control/status registers. For DCAN0 the control registers are located at 0x481cc000 and the message RAM is located as pg 4808 says 0x481C_D000. 

    If you are using the Linux driver then the control registers and message ram access is taken care of for you.

    There is not a need to modify the DTSI file here especially since the customer has it working.

    Best Regards,

    Schuyler

  • Hi Schuyler:

    THanks for your helping me always.

    2 more questions:

      A. Is there any user guide wiki to guide us hwo to porting the DTS/DTSI for DCAN0/DCAN1?

      B. What is the definition of Message RAM? Why only the DCAN needs the message RAM?

          For example: the I2C2 base address is : 0x481C_D000, I compared all the I2C2 keyword in the TRM, there is no message RAM for it.

          Why DCAN is so special to need the Message RAM?

    Thanks for your patient to help.

    BR Rio

  • Hi Rio,

    There is not a porting guide yet for DTS for DCAN, but you can use existing DTS files as an example. There is not required to port DCAN on the AM335x series. Please take a look at arch/arm/boot/dts/am335x-evm.dts and the dcan1 node which is the second dcan interface. You could cut and paste this node for dcan0 and change the pin mux to match the interface used and set the status to "okay". In the DTS file I mentioned is that a switch has to be set on the EVM to fully enable the interface and change to the DTS file to "okay".

    With regards to why message RAM is in the DCAN IP is only something I can speculate. First the IP is one that TI purchased from Bosch and integrated, it is not TI's IP. It has been around for a long time across several IP generations. I would imagine that with the RAM in the IP it makes it easier, lower latency etc. to send and receive messages and not have to integrate with SOC DMA support. 

    Hopefully this helps.

    Best Regards,

    Schuyler