TCAN4550EVM: CANBUS transmit data is unstable

Hi Hsinyu,

I'm not sure exactly what you mean by "the transmission is very unstable and the recipient does not always receive the data."  I don't know if this means the device is not responding to the transmission request and is not transmitting the message on the CAN bus for some reason which could indicate a clock related issue.  Or if this means that there are errors generated on the transmitted messages preventing a successful transmission to the receiving device.

Can you monitor the CAN bus during your test with a scope to see if there are any issues with the CAN waveforms during your test?  Are there any differences in the waveforms when you add an extra delay between the WriteTXBuffer and Transmit BufferContents functions?  Do you see any Error frames getting thrown on the CAN bus when you try to transmit?

Can you also monitor the various Status, Interrupt, Error Counter and TX Buffer registers to see if there are errors or problems getting flagged by the device?

0x0820 - Device Interrupts

0x0824 or 0x1050 - MCAN Interrupts

0x1018 - Control Register (monitor INIT bit)

0x1040 - Error Counter Register (CAN transmit and receive error counters)

0x1044 - Protocol Status Register (CAN specific status information including Error Codes)

0x10C4 - TX FIFO/Queue Status register

0x10CC - TX Buffer Request Pending (to see if messages are pending transmission)

0x10D8 - TX Buffer Add Request Transmission Occurred (to see if messages were successfully transmitted)

Regards,

Jonathan

Hi Jonathan,

Sorry for the late reply.

I'm connecting through stm32wb5 to tcan4550evm.

The program execution is shown below.

But there must be a 0.3-second interval for two CAN transmissions to be received by the device.

If less than 0.3 seconds, it's easy to encounter a situation where the second data cannot be candumped.

Is this delay time reasonable?

In theory, how long should the interval between two CAN transmissions be for tcan4550?

Hi Hsinyu,

The timing is based on a combination of the SPI and CAN bit rates, as well as the idle time between CAN and SPI messages.  You will need calculate the time your system needs to transfer the message contents into a TX Buffer element and transmit the message.  You could also simply measure this with a scope or logic analyzer to determine the time from start of the SPI to the CAN message transmission.

Because you are only using a single TX Buffer for both messages, you should also verify the first message has successfully transmitted before trying to load in the second message.  If you don't, and the TX message is still pending transmission, you could overwrite the TX buffer contents with the new message, or corrupt it with a partial overwrite as it is trying to transmit.

You may want to add a read to the TX Buffer Transmission Occurred (0x10D8) or the TX Buffer Request Pending (0x10CC) registers prior to your second message to verify the the status of the first message and whether it is safe to reuse the buffer for a new message.

You could also try to use multiple Dedicated TX Buffers, or a TX FIFO or Queue with more than one TX Buffer to avoid this potential issue.

Once the TX Buffer's bit has been set in the TX Buffer Add Request (0x10D0) register, the device will try to transmit as soon as possible based on the CAN bus activity and the protocol's rules of arbitration.  If there is other activity on the CAN bus, it may not be known exactly how long it will take for the message to be successfully transmitted, so verifying the TX Buffer is available is always good practice.

I would suggest you also review the MCAN User's Manual (Link) published by Bosch for more information on the CAN FD Controller IP used in the TCAN4550.

Regards,

Jonathan