AW: AW: [PATCH v4 7/7] can: m_can: Enable TX FIFO Handling for M_CAN IP version >= v3.1.x

["Huettel Mario (AE/PJ-SCI1)" <Mario.Huettel@de.bosch.com>]

Hello Wenyou,

I think I've found something suspicious:
*Both* M_CAN nodes are configured like this:
> bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>;

This means they're operating in the same memory region with exactly the same memory layout.
This does not have to be the cause of your problem but I think this is an error.


-----Ursprüngliche Nachricht-----
Von: Yang, Wenyou [mailto:Wenyou.Yang@Microchip.com] 
Gesendet: Dienstag, 18. April 2017 08:18
An: Huettel Mario (AE/PJ-SCI1) <Mario.Huettel@de.bosch.com>; Quentin Schulz <quentin.schulz@free-electrons.com>
Cc: linux-can@vger.kernel.org
Betreff: Re: AW: [PATCH v4 7/7] can: m_can: Enable TX FIFO Handling for M_CAN IP version >= v3.1.x

Hi Mario,

The device tree patch is attached.

Here is the configure and log.

---8<----

# ip link set can0 type can bitrate 125000 dbitrate 4000000 fd on 
fd-non-iso on
# ip link set can1 type can bitrate 125000 dbitrate 4000000 fd on 
fd-non-iso on
# ip link set can0 up
# ip link set can1 up
# ip -details link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN 
mode DEFAULT group default qlen 10
     link/can  promiscuity 0
     can <FD,FD-NON-ISO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) 
restart-ms 0
           bitrate 125000 sample-point 0.875
           tq 50 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1
           m_can: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..512 brp-inc 1
           dbitrate 4000000 dsample-point 0.700
           dtq 25 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1
           m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp-inc 1
           clock 40000000
# ip -details link show can1
3: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN 
mode DEFAULT group default qlen 10
     link/can  promiscuity 0
     can <FD,FD-NON-ISO> state ERROR-ACTIVE (berr-counter tx 0 rx 0) 
restart-ms 0
           bitrate 125000 sample-point 0.875
           tq 50 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1
           m_can: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..512 brp-inc 1
           dbitrate 4000000 dsample-point 0.700
           dtq 25 dprop-seg 3 dphase-seg1 3 dphase-seg2 3 dsjw 1
           m_can: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..32 dbrp-inc 1
           clock 40000000
# candump can1 &
#  cansend can0 5A1##111.22.33.44.55.66.77.88.99.aa.bb.cc
   can1  5A1  [12]  11 22 33 44 55 66 77 88 99 AA BB CC
#  cansend can0 5A1##111.22.33.44.55.66.77.88.99.aa.bb.cc
#

--->8----

Hope it is helpful for you.

Any question, please don't hesitate to come back.


Best Regards,

Wenyou Yang


On 2017/4/18 14:04, Huettel Mario (AE/PJ-SCI1) wrote:
> Hi Quentin, hi Wenyou,
>
> Today I've received another email that the driver is not working with the
> M_CAN in Atmel's SAMA5D2.
>
> Can you send me the device tree you're using and post the dmesg output
> of the m_can driver?
>
> There might be a clue why it isn't working.
> The fact that it is working one time and then stops working looks like some problem
> In the TX FIFO to me. Can you please check with some third device/oscilloscope,
> if the controller is sending data. I want to know ehre the problem lies. If it's in the TX or
> RX path.
>
> As for now I can only throw some ideas into the round:
> * What are the PCLK and CCLK values? CCLK >= PCLK?
> * TX FIFO configured to one element and something happens in that case.
> * No TX Event FIFO element configured. The driver also doesn't work in this case.
>
>
> Quentin wrote:
>> Hi Oliver,
>>
>> On 13/04/2017 08:30, Oliver Hartkopp wrote:
>>> Hi Wenyou,
>>>
>>> as Quentin had no problems in his setup:
>>>
>> Actually just retested by doing the same as Wenyou on my SAMA5D2
>> Xplained and I can attest I'm having the same behavior as Wenyou.
>>
>> Best regards,
>> Quentin
>
> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�b��\jx��\x17��ܨ}���Ơz�&j:+v���\r����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f