Continuing the discussion from Can function failed after flash pcie endpoint:
we use system: R32.6.1 and pcie ep mode
but we still have the question, it look like same topic.
you can help me to solve the question.
we log in the follow:
wicri@ubuntu:~$ dmesg | grep “can0”
[ 8.122204] net can0: mttcan device registered (regs=ffffff800b021000, irq=67)
[ 8.147893] mttcan c310000.mttcan can0: Bitrate set
[ 8.170632] mttcan c310000.mttcan can0: Bitrate set
[ 8.171318] IPv6: ADDRCONF(NETDEV_UP): can0: link is not ready
[ 8.171354] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[ 8.370306] mttcan c310000.mttcan can0: entered error warning state
[ 8.370590] mttcan c310000.mttcan can0: entered error passive state
and We found that when using RP mode it works fine.
I hope get help!
Sorry for the late response, is this still an issue to support? Thanks
yes, I still need your help!
Is it possible to test this on JP5.1?
yes ,I have tried upgrading the system to R35.1 and tested, but it still have the question.
Have you tested the same problem?
Please make sure you upgrade to Jetpack 5.1(r35.2.1).
please also check if reloading the mttcan driver can bring it back or not.
also, is loopback test able to reproduce this issue?
I think upgrading the system may be a good solution to this problem, but now we have designed the application and the drivers of the entire custom carrier board based on the R32.6.1 version, it is difficult for us to give up these designed things to upgrade the system , I hope you can understand, so I would like to know how to fix this problem without changing the system version
This is just for debug purpose for now. Not mean you need to do a total upgrade for your product.
Reloading the mttcan driver has no effect, and the loopback test is normal, as shown in the figure below.
At the same time, I will upgrade to R35.2.1 as soon as possible to test this module, thank you for your support
What is the failure usecase here if the loopback is still fine?
The problem I am talking about is that when I connect a real can device externally, I cannot communicate with it normally. When there are two external can devices, I find that I can receive data normally, but once I use cansend to send data, it will cause bus off.
But sending data won’t cause crash if you run loopback? I mean short the TX/RX pin.
yes, your understanding is correct
Does this issue require PCIe EP start running? Or just reflash the ODMDATA would cause it?
The strangest thing is that my hardware environment does not change in any way, just refresh the EP mode to RP mode, this problem will no longer exist, the can interface can send and receive.
It is difficult for me to determine whether it is caused by PCIe EP start running or refreshing ODMDATA. I may need to change the pcie ep-related driver compiled in the kernel into some modules.
please let us know after you find out which part is necessary to reproduce this issue.