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.
Tool/software:
HI TI team,
I am using the official TCAN demo, and the contents of the initialized Init_CAN() are as follows. At present, I am sending data to TCAN4550 through MCU SPI. TCAN4550 can forward it to other devices and the devices can also receive it. But the interrupt pin of TCAN4550 is not pulled down for CAN data sent by other devices. In the initialization phase, the interrupt pin will report multiple interrupts to interact with the MCU to complete initialization, so the interrupt pin is working normally.
The nINT pin is working normally because if I manually pull down the nINT, the STM32 MCU can receive interrupts
I captured the waveform of the initialization part of the code above, and I can see that the interrupt nINT can be triggered normally after resetting the chip, but the subsequent data reception cannot notify the MCU
During the initialization process, the two data frames sent by the above code can be received by other devices
So I want to know under what abnormal circumstances does TCAN4550 not pull down the nINT pin after receiving a CAN message?
My hardware environment here is flying from the demo board on the left to the STM32 board on the right. Could it be that the demo board requires some configuration to make nINT work properly?
Some messages can be received, but some cannot, so I suspect it may be a problem with the filter settings. I want to know how to receive all incoming messages without filtering any messages. How can I configure it in Init_CAN()
Hi Zhicheng,
So I want to know under what abnormal circumstances does TCAN4550 not pull down the nINT pin after receiving a CAN message?
The nINT pin is the Logical OR of all enabled interrupt bits reflected in registers 0x0820 and 0x0824. Note that register 0x0824 is a read only copy of register 0x1050.
To get the nINT pin to reflect a set bit such as the reception of a new message, we simply need to enable the interrupt bits properly.
From your MRAM configuration, it looks like you are using RX FIFO 0 to receive your messages. However, it doesn't appear that the RX FIFO 0 New Message Interrupt Enable is being set and that line is commented out, and otherwise would be set to 0 (disabled).
TCAN4x5x_MRAM_Config MRAMConfiguration = {0};MRAMConfiguration.SIDNumElements = 0; // Standard ID number of elements, you MUST have a filter written to MRAM for each element definedMRAMConfiguration.XIDNumElements = 8; //1 aizj // Extended ID number of elements, you MUST have a filter written to MRAM for each element definedMRAMConfiguration.Rx0NumElements = 32; //2 aizj // RX0 Number of elements RemoteFrame <32;STD 64MRAMConfiguration.Rx0ElementSize = MRAM_64_Byte_Data; // RX0 data payload sizeMRAMConfiguration.Rx1NumElements = 0; // RX1 number of elementsMRAMConfiguration.Rx1ElementSize = MRAM_64_Byte_Data; // RX1 data payload sizeMRAMConfiguration.RxBufNumElements = 64; // RX buffer number of elementsMRAMConfiguration.RxBufElementSize = MRAM_64_Byte_Data; // RX buffer data payload sizeMRAMConfiguration.TxEventFIFONumElements = 0; // TX Event FIFO number of elementsMRAMConfiguration.TxBufferNumElements = 8;//2; // TX buffer number of elementsMRAMConfiguration.TxBufferElementSize = MRAM_64_Byte_Data; // TX buffer data payload size
/* Set the interrupts we want to enable for MCAN */TCAN4x5x_MCAN_Interrupt_Enable mcan_ie = {0}; // Remember to initialize to 0, or you'll get random garbage!//mcan_ie.RF0NE = 0; // RX FIFO 0 new message interrupt enablemcan_ie.RF0WE = 1;mcan_ie.RF0FE =1;TCAN4x5x_MCAN_ConfigureInterruptEnable(&mcan_ie); // Enable the appropriate registers
In order to receive a new message Interrupt from RX FIFO 0, the following bits need to be set:
RF0NE=1 (0x1054[0])
RF0NL=0 (if using Interrupt line 0 which is default) or =1 (if using Interrupt line 1) (0x1058[0])
EINT0=1 (if using Interrupt line 0) or EINT1=1 (if using Interrupt line 1) Enabling both is ok, but the line used for 0x1058 needs to be enabled. (0x105C[1:0])
Configuring those bits should allow any new message received into the RX FIFO 0 to be reflected on the RF0N bit in the MCAN Interrupt Register (0x1050[0] and 0x0824[0]).
Some messages can be received, but some cannot, so I suspect it may be a problem with the filter settings. I want to know how to receive all incoming messages without filtering any messages. How can I configure it in Init_CAN()
The Global Filter Configuration register (0x1080) can be configured to accept all non-matching frames. By default all non-matching frames will be stored into RX FIFO 0, so you will want to configure this register to accept instead of reject non-matching frames.
The configuration code shows the device is configured to reject instead of accept, so you will want to comment out the "reject' lines and uncomment the "accept" lines of code.
/* Configure the default CAN packet filtering settings */TCAN4x5x_MCAN_Global_Filter_Configuration gfc = {0};gfc.RRFE = 0; //1 // Reject remote frames (TCAN4x5x doesn't support this)gfc.RRFS = 0; //1 // Reject remote frames (TCAN4x5x doesn't support this)gfc.ANFE = TCAN4x5x_GFC_REJECT; // Default behavior if incoming message doesn't match a filter is to reject for extended ID messages (29 bit IDs)gfc.ANFS = TCAN4x5x_GFC_REJECT; // Default behavior if incoming message doesn't match a filter is to reject for standard ID messages (11 bit IDs)// gfc.ANFE = TCAN4x5x_GFC_ACCEPT_INTO_RXFIFO0; // Default behavior if incoming message doesn't match a filter is to accept into RXFIO0 for extended ID messages (29 bit IDs)// gfc.ANFS = TCAN4x5x_GFC_ACCEPT_INTO_RXFIFO0; // Default behavior if incoming message doesn't match a filter is to accept into RXFIO0 for standard ID messages (11 bit IDs)
Regards,
Jonathan
Hi Jonathan,
This is very useful. We can now receive CAN messages, but there is an issue where when TCAN4550 receives a frame of message, it will pull down the nINT pin to notify the MCU to retrieve the packet. The MCU also responds to the interrupt and retrieves the packet, but after the MCU retrieves the packet, nINT does not pull up, but keeps pulling down. This leads to the problem that TCAN4550 receives the second frame message and nINT remains low, making it impossible for MCU to trigger interrupts to retrieve packets
Hi Jonathan,
The waveform below shows the timing sequence of TCAN4550 receiving a frame of message and forwarding it to MCU. It can be seen that after MCU reads the message, nINT remains at a low level
The MCU has cleared the IR interrupt after reading the TCAN4550 data.But we still can't raise nINT. The code for the clear IR register is as follows:
Hi Jonathan,
After encountering the issue where nINT cannot be pulled high, I found that when nINT cannot be pulled high, the SPIERR bit of the 0x820 register is set to 1. Therefore, after adding a clear SPIERR bit operation in the following locations of your demo code, nINT can now be pulled up normally. But there must be a problem with this. Why do I always set the SPIERR bit to 1 every time I receive a package.
Hi Jonathan,
thanks a lot for your help. This is Yang (I contacted you in webex). I am also looking at this issue and find this similar post:https://e2e.ti.com/support/interface-group/interface/f/interface-forum/981125/tcan4550-nint-latches-active-for-unclear-reason-possibly-wup-related
So, I asked Mr. Zhang to check 0h0820 & 0h0824 if the device goes into sleep mode, please correct me or if you have more comments. thanks a lot.
Best regards,
Yang
Hi Zhicheng and Yang,
SPI Errors are generally due to an incorrect number of SPI clock pulses detected while the nCS pin is low. The device uses a FIFO to handle the frequency domain transition between the SPI clock frequency and the OSC clock frequency and an incorrect number of clock pulses can result in errors with passing data into and out of this FIFO
Because the device uses 32-bit words for the registers and MRAM, the device will count the number of clock pulses to make sure that it is an exact multiple of 32. If there are to few or to many pulses, this could cause the data transmitted to be incorrect and the SPIERR flag is set.
The device also verifies that the number of clock pulses matches the number of data bits expected in the transaction which can vary with the Length field. For a single register read/write, the Length Field should be set to 0x01. The TCAN4550 will then expect a total of 64 SPI Clock pulses while the nCS pin is low.
Multiple consecutive register or MRAM locations can be accessed by setting a larger value for the Length field. For example if the Length field is set to 0x02, a total of 96 SPI Clock pulses would be expected.
However, the Length field should never be set to 0x00. I looked back at your previous logic analyzer plot and found that you have a SPI Write (0x61 op code) that has the Length Field set to 0x00. This would result in a SPI Error because there would not be an extra 32 data bits clocked into the FIFO that is not expected.
Can you verify your code is correctly setting the Length field to 0x01 during SPI Writes and see if this resolves the SPI Errors you are seeing?
Regards,
Jonathan
Hi Jonathan,
Did the specification sheet explain this issue? After I changed it to 0x01, SPIERR did indeed disappear.
Hi Zhicheng,
Yes, the SPI Errors are related to an incorrect number of SPI Clock pulses, or data bits because each SPI Clock pulse represents a single Data bit. Therefore, an incorrect number of clock pulses results in an incorrect number of data bits with either too few, or too many bits, and this can cause doubt about the validity of the data. Therefore this is considered and Error and the attempt is to prevent corrupting the register configuration with bad values.
Regards,
Jonathan