TDA4VM: TDA4VHQ1开发板在使用MCAN模块时，不能进行正常通信

Hi,

Can you ask the question in English please.

Regards,
Tanmay

Hi， In standard CAN mode and CANFD mode, communication can only be done when the arbitration segment is 1 Mbps, and setting other values, such as 500kbps, will cause communication failure.
The following is the error message prompted by CANOE。Please help me analyze what might be causing this，Thank you！

Hello,

May i know which CAN driver you are using ? SDK version details and how did you change from  1 Mbps to 500 Kbps ?

Regards

Tarun Mukesh

Hello, the driver of MCAN I am currently using, the SDK version is ti-processor-sdk-linux-adas-j784s4-evm-11_00_00_08, as for switching the baud rate, I set the baud rate through the ip link set main_mcan4 type can bitrate 500000 command

Hi Wzzz,

Can you check that the sample-point, arbitration "bitrate", and "dbitrate" (for CAN-FD) are all the same between the TDA4VH and CANOE device?

Regards,

Takuma

Hi, Takuma, I confirm that the "bitrate", "dbitrate" and "sample-point" and "dsample-point" configurations between TDA4VH and CANOE are consistent, and currently at 1Mbps I can send to CANOE through TDA4VH, and CANOE can also receive normally, but on the other hand, send to TDA4VH through CANOE, TDA4VH cannot receive CAN frames

Hi Wzzz,

Strange that it only works in one direction. Can you confirm if "candump" is running?

Regards,

Takuma

Hello Takuma，

 I'm sure candump is running. I also tried to grab the waveform with an oscilloscope, and found a little abnormality, I will attach two pictures, we use two CAN (mcu_mcan0, mcu_mcan1) on the TDA4VH for spontaneous self-reception, whether it is CAN or CANFD mode, it can communicate normally, but once connected to CANOE for comparison, an error will occur, resulting in bus-off, we make sure that the baud rate and other configurations of CAN on TDA4VH are consistent with CANOE. The terminal resistors also have normal connections.I found that at the end of the CAN frame, the waveform was a bit abnormal.

Hi Wzzz,

So far, it sounds like only when CANOE is transmitting, the TDA4VH cannot receive the packet.

Can you send the output from the following command:

• ip -details link show mcu_mcan0

And can you also share the same information from the CANOE device?

Regards,

Takum

Hi Takum，

Judging from the current situation, after connecting to CANOE, it cannot communicate normally. I used the ip command to check the status of the CAN controller, and also checked the configuration information of CANOE, which I attached. After an abnormal communication, use the ip command to view the status of the controller, the status is "ERROR-PASSIVE" and "BUS-OFF".

Regards,

Wzzz

Hi Wzzz,

Can you also show the sample-point, clock, qlen of the CANOE so that we can do a comparison? If those settings do not exist in the CANOE tool, can you search for documentation that has this information? 

Regards,

Takuma

Hi Takuma，

Here is the detailed configuration of CANOE，these include configurations such as sampling points and clocks.

Regards,

Wzzz

Hi Wzzz,

It looks like the sampling point setting is different between CANOE and the TDA4VH. CANOE is 0.75 while TDA4VH is 0.875.

Regards,

Takuma

Hi  Takuma,

I don't think the setting of the sample point has much to do with whether the standard CAN mode can communicate, of course, I will set the sample point to be consistent when I test.

Regards,

Wzzz

Hi Takuma,
Because we have used TDA4VH samples before, there is no problem with it, but after replacing it with a mass-produced chip this time, the CAN communication is abnormal. In the previous test process, we did not specifically set the sample point in CAN mode, and we have always used the default sample point configuration, and there is no problem in the test. After replacing the mass-produced chip this time, we specially went to the same sampling point for testing, but it still didn't work.

Regards,

Wzzz

Hi Wzzz,

1. What is the specific part number for "TDA4VH samples" and what is the specific part number for "mass-produced chip"? 
2. How many boards are having the CAN issue? And how many total boards are there? 
3. Are there any difference in software? For example, is the same SDK version used for sample and mass-produced chip boards?

Basically, I would like to understand if this is a systematic issue where all boards are having the CAN issue, or if it is a rare failure. And I would like to understand if there is any difference in software.

Regards,

Takuma

Hi Takuma,

Thanks for the reply!

1.The sample model we used before was:XJ784S4GAALY, the models of the mass-produced chips currently used are:TDA4VH88TGAALYRQ1.

2.Currently, all boards that use production chips have problems with CAN communication, and there are also problems with SERDES.

3.There are no changes in the software, we are still using the same version of the SDK as the sample "XJ784S4GAALY", and these functions have been successfully debugged on the sample, but there is a problem with the new mass production chip "TDA4VH88TGAALYRQ1", and we also doubt whether the SDK has been updated, and after debugging with the latest version of the SDK, the problem still exists. 

Regards,

Wzzz

Hi Wzzz,

Software should be compatible between XJ784S4GAALY and TDA4VH88TGAALYRQ1. They should both have same number of MCAN and SERDES lanes. 

Can you share the schematics of how the signal from SoC for MCAN is routed to MCAN pins?

Regards,

Takuma

Hi Takuma,

We also use the mass-produced chip "TDA4VH88TGAALYRQ1" because the two chips are compatible with each other, and the schematic is almost unchanged compared to the "XJ784S4GAALY" chip, and the previous schematic design is directly reused.

Hi Wzzz,

Can you also share the XJ784S4GAALY version of below schematics?

I am not knowledgeable with the connection for this particular CAN transceiver, but I would like to understand if there are any difference with the RXD, EN, STB, and WAKE pins. I see the RXD pin has a pull-up resistor which typically is not necessary, and WAKE is pulled down.

Regards,

Takuma

Hi Takuma,

I will attach the schematic design of the chip "XJ784S4GAALY", as you said, compared to the previous principle, it does add a pull-up resistor to the RX pin of the CAN transceiver. Could this be the cause of the communication failure?

Regards,

Wzzz

Hi Wzzz,

As an experiment, could the pull-up resistor be removed?

I am not aware of a requirement to pull up the RX line for CAN, so I am not sure what the effect is for including the resistor or removing the resistor. However, since the issue is happening only on the RX, and a difference between working and non-working system is the pull-up resistor on the RX line, removing the pull-up would be a good experiment.

Regards,

Takuma

Hi Takuma,

I can try to see if I can remove the pull-up resistor on the RX and test it. However, not only RX is a problem, but also TX, as I described before and attached pictures, I use TDA4VH as the transmitter and CANOE as the receiver, CANOE cannot receive data correctly, only when TDA4VH and CANOE are configured in CANFD mode, and the baud rate is set to 1Mbps, the communication is normal. In standard CAN mode, there are problems with both TX and RX, you can look through the images I provided earlier, this should help us identify the problem as soon as possible.

Regards,

Wzzz

Hi Wzzz,

I took a look at the schematics a bit more and noticed that the CAN transceiver used in old working and new non-working system are different. So, I do not think this is an issue with sample vs mass-produced chips. Instead, I think it is more reasonable to suspect the issue is due to the hardware changes done on the new board related to the CAN transceiver.

So please, continue with the RX pull-up resistor change. I also noticed that the VBAT related connection is slightly different, and there is slight difference with the termination due to SPLIT termination.

Regards,

Takuma

Hi Takuma,

We tried removing the pull-up resistor on the RX for testing, and it was still the same as before. For the change you said about the split terminal, our CAN transceiver has changed from TJA1043 to TJA1063, it seems that TJA1063 does not need a split terminal, and we also tried to change the TJA1063 to the original TJA1043 transceiver for testing, but it still can't communicate.

Regards,

Wzzz

Hi Wzzz,

Can you share the devicetree used for TJA1043 and TJA1063?

Regards,

Takuma

Hi Takuma,

I'll attach the device tree configuration for both transceivers.The number of devices we TJA1043 and TJA1063 use is the same, nothing has changed.

TJA1063:

TJA1043:

Regards,

Wzzz

Hi Wzzz,

The change with standby and enable gpios is significant. What is the reason for commenting out standby gpio for working TJA1043 case?

As shown below, not defining standby-gpios should cause an error in the transceiver driver, so I assume there were changes done to the Linux kernel driver. There may be some changes in the kernel driver which might be conflicting with TJA1063 since ti,tcan1043 and ti,tcan1042 both use the same kernel driver. 

Regards,

Takuma

Hi Takuma,

I think the purpose of the standby and enable configuration here is to control these two pins and get the transceiver into a working state. The 1043 device tree notes standby because standby is raised by default and does not need to be controlled.

Regards,

Wzzz

Hi Wzzz,

You are right, the standby/enable is using the optional API, so error should not necessarily be triggered. Hardware-wise, the old and new board looks to have standby floating and not pulled up or down, so it is a bit strange though.

Other than the CANOE device, are there any other devices you can test the TDA4VH CAN interface?

Regards,

Takuma

Hi Takuma,

During testing, I controlled the standby and enable pin states of the transceiver via GPIO and measured them with a multimeter to ensure that the pin state was properly controlled. As I said before, the TDA4VH can communicate with tools such as CANOE at certain baud rate settings, so I think the transceiver should be in a normal working state. In addition to CANOE, we also tested it with ZCANPRO, and the results were the same as before.

Regards,

Wzzz

Hi Wzzz,

Let me assign this thread to our hardware team to see if they have any input.

Regards,

Takuma

Hello Wzzz,

Does a pre-production part work on the new board? And vice-versa- does a production part work on the old board? I would like to confirm the behavior of pre-production vs production part on the new and old boards.

Hi Takuma,

Okay, thank you very much！

Regards,

Wzzz

Hi Mark,

We have taken the new board to the factory and pasted the old chip on the new board to see if it works, but it will take a few days.

Regards,

Wzzz

Hi Mark,

After we replaced the old chip, we verified it again, and the phenomenon was still the same as before. Can you provide some directions for troubleshooting?

Regards,

Wzzz

Hi Wzzz,

Could you please capture CAN waveforms from a passing case and a failing case? Please include the TX, RX, and EN signals coming from the SoC for both cases.

Hi Mark,

After replacing the old chip "XJ784S4GAALY", we tried again and found that most of the problems we encountered before had been solved, but the current use of mass-produced chips "TDA4VH88TGAALYRQ1" is still not good, and the situation is the same as before.For the waveform of the CAN signal, I have uploaded the normal and abnormal waveforms of the TX signal before.

Wzzz

Hi Wzzz,

If I understand correctly, you retested the pre-production part on the new board and it is now working despite previously not working. Can you please fill out the following table for us to understand conditions and results?

Can you please confirm if you're seeing this issue on all CAN instances?

Also, please provide TX, RX, and EN waveforms at the SoC in a working and a non-working case (eg. TP6501, TP6502, and whichever test point at the SoC for CAN1_EN in your new schematic), so we can know the SoC CAN bus behavior in both cases.

Hi Mark，

Sorry to reply to you so late.

I will add the waveforms of TX, RX, and EN signals later.

Regards,

Wzzz

Waveform in non-operational mode：

Waveform in normal operating mode：

Normal TX signal in working mode：The two CAN channels of the TDA4VH are connected to each other, and there is no abnormality in the TX signal.

Abnormal TX signal in operating mode：When connected to CANOE or an external device, the end flag of the TX signal is abnormal.

RX signal in working mode：As you can see, the waveform of the RX is correct, but the data is not received using candump.

Hi Mark,

Please help analysis based on customer's waveforms. Customer told me that they have 4 non-working boards all using the TDA4VH88TGAALYRQ1, they switch one of these boards to XJ784S4GAALY, just change TDA4VH88TGAALYRQ1 to XJ784S4GAALY on this board, keeping the rest parts the same, the problem seems disappeared, and the results customers provided in the above reply shows abnormal (other boards using TDA4VH88TGAALYRQ1) & this new board after switching to XJ784S4GAALY.

I do suspect there is some HW related designs need to be optimized from the experiment result, any clue you could share please?

Thanks,

Kevin

Hi Wzzz,

1. Can you please confirm where in the schematic you're probing when capturing the TXD signal in the working and failing case?
   1. Can you probe at various points in the TXD signal path and share the results (eg. TP6505 at SoC, TP1301 after the digital isolator and before the CAN transceiver)? We would like to know how this signal looks at various points before and after the digital isolator in its path.
   2. Same as above for RXD signal.
2. Why is there a pull-up resistor on the RXD line between the digital isolator and CAN transceiver?
3. Does the TDA4 SoC report any MCAN errors in the failing case?
   1. Please refer to MCAN Protocol Status Register section in MCAN Debug Guide

Both pre-production part and production part are the same silicon revision so there are no differences expected with the MCAN.

EDIT: Few more items to check if you could please.

1. Are there any electrical shorts between TXD and RXD signals?
2. Is TJA1463 VIO stable?
3. What is J6503? Is this a connector?

Hi Mark,

1.These signals are measured at the test point between the isolator and the transceiver, as shown in the figure below. 

2. The pull-up resistor on the RX is reserved by us. We also tried removing this pull-up resistor for testing, but there was no change. Will this pull-up resistor have any impact on communication?

3. I will supplement the status of these registers later.

The answers to the several questions you supplemented are as follows.

1. There is no short circuit phenomenon between RX and TX.

2. The VIO power supply is stable.

3. J6503 is a board to board connector.

Regards,

Wzzz

We also tried to replace our currently used CAN transceiver with the TI 1043 transceiver for testing, and the result was the same as before.

Hi Wzzz,

Thank you for addressing most of the questions.

Wzzz w said:

1.These signals are measured at the test point between the isolator and the transceiver, as shown in the figure below. 

Can you please provide TXD signal waveforms before the digital isolator?

Wzzz w said:

Will this pull-up resistor have any impact on communication?

This pull-up resistor is likely ok. It will ensure the transceiver output's recessive state is standby or sleep mode.

Hi Mark,

I have pushed customer to provide the TXD signal waveforms as soon as possible. And before you receive that, here is a full log dump with very detailed comparison between the TDA4VH88TGAALYRQ1 & XJ784S4GAALY. We indeed could see some register dump difference and hope this could provide more clue for you to figure out the problem.

Could you please have a look of this excel sheet please? Customer spent a lot of time to get this. (it includes idle state, Rx, Tx, separately)

1882.MCAN Reg Dump.xlsx

Thanks,

Kevin

Hi Kevin, Wzzz,

Are there any other CAN devices you can try to test the TDA4VH with? So far, it sounds like we have verified that TDA4VH can communicate at different speeds with itself, and CANOE can communicate with ZCANPRO. Is it possible to test TDA4VH and ZCANPRO combination? Or, if I interpreted your information wrongly and you have already tested TDA4VH + ZCANPRO, is it possible to test with CANOE + ZCANPRO, and test that different arbitration and data speeds can be set?

As for the register dump and reason why it would be good to test with other devices, the register dump seems to point to issues during initialization. 

For RX:

A "Protocol Error in Arbitration Phase" interrupt is being set for failed case. As mentioned at start of the thread, I have seen this when there is a mismatch between receiver and transmitter for sample-point, the lower speed arbitration bitrate, and/or data bitrate.

Additionally, nothing looks to be in RX FIFO for failed case based on RXF0S and RXF0A, also pointing to failure during arbitration.

For TX:

Based on CCCR bit 1 being set, also looks to be some issues in init/sync. TXBTO and TXBRP is also interesting for TX since each bit represents some transmission had occurred or not, and in "Fail" system it looks like some transmissions occurred, but not all.

Regards,

Takuma

Hi，Takuma

According to Mark's suggestion, we measured the TX and RX before isolation, and the results are as follows.

TX：

RX：

Currently, we have tested the several forms you mentioned. The TDA4VH itself can communicate through its two CAN channels, but it cannot communicate properly with CANOE or ZCANPRO. However, CANOE and ZCANPRO can communicate normally with each other, and we have also changed the transmission rate and sampling point for testing, and both sides can communicate normally.

For RX：

During the testing process, we first ensure that the parameters on both sides remain consistent, but the RX still cannot receive any data.

For TX：

You are correct in your understanding; during the transmission process, some parts were transmitted while others were not, resulting in the bus entering a bus-off state.

Regards,

Wzzz

Hi Wzzz,

Thanks for sharing the waveforms but I believe these are inconclusive without seeing the SoC transmit or receive any CAN packets. I would have expected to see something similar to probing in between the digital isolator and the transceiver.

Regards,
Mark