Asking about the CAN FIFO full & watermark interrupt

[GlJe_1688511]

Hello.

I am testing the CAN FIFO interrupt.

I attached the sample code.

The code doesn't occur the interrupt of CAN FIFO full & watermark.

Please review the code.

Thanks and Best regards.

Glenn.

[Kavya_B]

Hello Glenn,

One observation from the code you shared is that the interrupt for Tx FIFO Empty (TFE) is not enabled but you are checking for that interrupt in main_cm4.c file.

Could you please mention which is the Traveo II device you are using for testing? I will try to test at my end come back with my observations.

Thanks,

Kavya

[GlJe_1688511]

Hello Kavya.

I used the TRAVEO II Starter kit and TRAVEO II SDL 7.1.0.

The TxFIFO Empty interrupt worked well.

After testing the Tx FIFO Empty, I disabled the TFE for testing the CAN FIFO full & watermark interrupt.

Thanks and Best regards.

Glenn.

[Kavya_B]

Hello Glenn,

I tested the CAN example you shared on SDL 7.1.0 using Traveo II starter kit. Below are the observations:

a) If I test the example as it is, I do not see 'Tx Event FIFO Full' (TEFF) or 'Tx Event FIFO Watermark Reached' (TEFW) interrupts. I could verify that there was no issue with respect to interrupt configuration or any other configuration of CAN in your example.

b) As you had seen during your testing, if I enabled 'Transmission Complete' (TC) and 'Tx FIFO Empty' (TFE) interrupt in Interrupt Enable register, then these bits were set in Interrupt Register and corresponding interrupt was triggered as expected.

The reason for not getting Tx FIFO not full or Tx FIFO watermark not reached interrupts is because, the test setup with just two nodes in a CAN network (Traveo II as one node and a simple CAN analyzer as another node in the CAN network) is NOT simulating a condition where Tx FIFO becomes full and triggers corresponding interrupt. It could be seen that after every transmission the Tx FIF was empty (please see the attached screenshot).

A CAN network with more number of nodes in it and with a heavy bus load may be required to simulate this condition. If a node doesn't win the bus due to loss of arbitration for a considerable time may help to simulate the test condition (Tx is not successful due to loss of arbitration on the CAN bus and the next messages to be transmitted get accumulated in the Tx FIFO filling it and making it to reach watermark).

Thanks,

Kavya

[GlJe_1688511]

Hello Kavya.

I tested it by sendin the register data by CAN message.

There is the FIFO full in CAN message.

Logic Analyzer Viewer : https://www.dreamsourcelab.com/download/

Thanks and Best regards.

Glenn.

[Kavya_B]

Hello Glenn,

I checked the code you shared in your last post. I could see that you are updating data[0] byte of the message with value of TXFQS register of the CAN FD channel which you are using and data[1] byte with content of IR register.

As per the Logic analyzer screenshot you shared, data[0] is 0 (which represents the value of TXFQS register) and data[1] is 0x04 which only contains some Rx related interrupt bits set in IR register. I didn't really understand how you are considering that Tx FIFO is full.

You have highlighted data[2] in the screenshot. As per the code data[2] is not updated with any significant value. What is the value 0x24 indicating? Please explain if I'm missing anything here or if I'm not understanding what you are trying to convey.

Thanks,

Kavya 

[GlJe_1688511]

Hello Kavya.

Thanks.

The Data[0] and Data[1] are 32 bit Data.

The 0x24 of Data[0] are TFQF and TFQPI[20:8]

Because the TFQF is 0x01, The FIFO is full.

So, the FIFO full interrupt must have occurred.

But, the interrupt didn't occurred in the firmware.

Is my thinking wrong?

Thanks and Best regards.

Glenn.

[Kavya_B]

Hello Glenn,

If I see the main_cm4.c file you shared in 'CAN_FIFO.zip' folder on this thread, you have configured it for Classic CAN operation and not as CAN FD. Please see the attached screenshot or line number 273 in main_cm4.c file you shared.

Also, if you see in the screenshot of the logic analyzer you had shared, the DLC is 8 i.e. 1000 (because the same is configured in your code). Hence the message contains totally 8 bytes of data. Even if you are copying the complete value of TXFQS register (which is of 32 bytes) into the data field, the complete value cannot be taken into the actual data field of the CAN message and  'data byte:2' in the logic analyzer screenshot is not representing the condition of Tx FIFO full.

Thanks,

Kavya

[GlJe_1688511]

Hello Kavya.

The TXFQS register is 32 bits register(4 Bytes).

So, the CAN message have the full of the register.

I attached the capture images.

Thanks.

Glenn.

[Kavya_B]

Hello Glenn,

Your observations regarding TXFQS register and Tx FIFO full condition being triggered sometimes during the test is true. I apologize for misinterpreting the code and the logs.

I ran the test again, analyzed the code and verified that the byte 0 to byte 3 in every CAN message is representing the value of TXFQS register and sometimes the FIFO full condition becomes true (21st bit in TXFQS register is set). I analyzed further on why IR.TEFF or IR.TEFW bits are not set even if the Tx FIFO is full.

In the CANFD hardware module, 'Tx FIFO' and 'TX Event FIFO' are two different entities. Tx FIFO is used to store the messages to be sent. You can see the status of this with help of TXFQS register (i.e. Tx FIFO/Queue Status register. This is the register you were monitoring in your test). 

TX Event FIFO is used during TX event handling. After the M_TTCAN has transmitted a message on the CAN bus, the Message ID and timestamp are stored in a Tx Event FIFO element. The status of Tx Event FIFO can be found in TXEFS register (i.e. Tx Event FIFO Status register). The bits TEFL_, TEFF, TEFW and TEFN in IR register are associated with Tx Event FIFO status, not with TX FIFO status. The only bit in IR register that is associated with Tx FIFO is TFE (Tx FIF Empty).

Please refer to sub-sections '23.3.5.3 TX FIFO' and '23.3.5.8 TX Event Handling' in Body Entry Architecture TRM (Document No. 002-19314 Rev. *H).

Thanks,

Kavya

[GlJe_1688511]

Hello Kavya.
I understand it about the FIFO full interrupt.

But, the FIFO watermark interrupt should occur, isn't it?

Thanks and Best regards.

Glenn.

[Kavya_B]

Hello Glenn,

To verify the water mark reached interrupt for Tx Event FIFO (IR.TEFW), I modified the code you had shared to make TXEFC.EFWM = 1 so that it should be faster to reach water mark condition. Please see the attached screenshot. But even with this setting, I could not see IR.TEFW interrupt bit getting set during my testing.

Let me please discuss on this behavior with our internal team and come back to you after the analysis.

Thanks,

Kavya

[Kavya_B]

Hello Glenn,

I would like to provide some updates based on the discussion with our internal experts regarding 'Tx Event FIFO Watermark Reached interrupt not getting set'.

It was recommended that 'EFC' bit in Tx Buffer Element should be set while transmitting so that Tx Event FIFO is updated after every message transfer. I modified the driver file (canfd.c) to incorporate this change while transmission. But even then I didn't observe that IR.TEFW was set.

Following are the conditions for IR.TEFW interrupt to get set as explained by our internal experts:
- The number of completed transmissions are equal or more then the watermark value.
- EFC bit is set in the Tx Buffer Element.
- IE.TEFWE (Tx Event FIFO Watermark Reached Interrupt Enable) is set to 1

I tested with implementing all the above mentioned conditions. Please see the screenshot from cycanfd.c file and the register log captured out of my test attached with this response (All the remaining code is unchanged and retained as in the files you shared).

From the register value of TXEFS, it seemed that elements were stored Tx Event FIFO correctly.
- TXEFS.TEFL=1: Tx Event FIFO Element Lost due to overflow
- TXEFS.EFF=1: Tx Event FIFO full
- TXEFS.EFFL=4: Number of elements stored in Tx Event FIFO is 4 (full)

But even then IR.TEFW bit was not set. It has been informed that, the condition for IR.TEFW to be set to 1 is:
- When TXEFS.EFFL is increased from "TXEFC.EFWM - 1" to "TXEFC.EFWM"
There is no other conditions. Even if IE.TEFWE=0, IR.TEFW can be set.

Now, our internal team recommend the following steps to confirm the operation:
1. Monitor TXEFS.EFFL bits
2. Monitor IR.TEFW bit
3. Check if IR.TEFW bit is set when TXEFS.EFFL is increased from "TXEFC.EFWM - 1" to "TXEFC.EFWM"

One observation from the register log obtained during my test was (may not be directly related to this issue), IR.ARA was set to 1. This means that an access to reserved address had occurred.

I will continue to test. I request you also to consider the recommendations and proceed testing and please let us know your observations.

Also, please see if you also see IR.ARA bit set.

Thanks,

Kavya

[GlJe_1688511]

Hello Kavya.

Thanks.

I attached the data.

But,IR.TEFW bit doesn't become 1.

Thanks and Best regards.

Glenn.