Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Power Management ICs Forum Discussions

LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

Hello, Dear Infineon Technical Engineer:

We are currently developing functional safety software for the TLF35584. There are several questions about the SPI write command parity error retransmission mechanism of TC377 + TLF35584:

1. According to the functional safety manual: " In case the parity information during a write operation is incorrect, the TLF35584 will ignore the data and respond with an interrupt. The microprocessor should service the interrupt and check the interrupt source, i.e. check if the SPI.PARE bit is set. In case of a failed write operation, the microprocessor should repeat the operation.
"

 

LuckyDu_1-1658286281519.jpeg

 

We use the TLF35584_INT + TC377_NMI interrupt method to retransmit.

We now have a question in this way: because the TLF35584 interrupt has a minimum clearing time of 100us, and then there is a 300us time for the next interrupt to be generated. If I have consecutive SPI parity errors, only the first frame of SPI data error can pull the INT interrupt signal low (generate an interrupt source), and the rest of the SPI signals are in the INT low condition (cannot generate interrupts) . In this case, only the first frame of SPI data can be retransmitted, and subsequent retransmissions cannot be performed.

LuckyDu_2-1658286297535.jpeg

LuckyDu_3-1658286305473.jpeg

 

Take an extreme example: if all 10 consecutive SPI commands of the TC377 have a parity error problem. But only the first frame of the SPI command can generate an interrupt source and perform a retransmission. The remaining 9 frames cannot generate an interrupt because the INT signal is low. This just resends a frame of SPI commands.

2. How is the retransmission mechanism recommended by Infineon handled? Can you describe it?

Do you have a demo that you can provide us with the retransmission mechanism of 35584_SPI?

0 Likes
10 Replies
dw
Moderator
Moderator 10 likes given 500 replies posted 50 likes received
Moderator

Hi LuckyDu,

For a SPI command, which includes multi bytes. So if one byte has a parity error, the whole command will be discarded.

So, if the MCU gets the interrupt of the error, then it needs to retransmit the command.

The machanism depands on the customer's need. Here is an example:

Send first command.

Check the ACK. (If error then resend)

Send second command.

Check the ACK. (If error then resend)

 

If the error number accumulated to specified number, then the bus could be broken and the MCU could think it's a FAULT and process accrodingly, i.e. blinking a LED to notify that the SPI bus is in FAULT status.

dw

0 Likes
LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

In view of the above situation, we have come up with the following solutions:

Do not use INT+NMI interrupt, and follow a Read SPISF.PARE command after each write command is completed. If SPISF.PARE=1, a retransmission will be performed immediately, and after the retransmission is completed, Clear SPISF.PARE. This allows each SPI command to be retransmitted after a parity error.

Is it reasonable to follow a Read command after each write command?

 

Concern: The above situation has nothing to do with the INT interrupt of 35584, so whether it does not meet the situation described in the functional safety document.

0 Likes
dw
Moderator
Moderator 10 likes given 500 replies posted 50 likes received
Moderator

Hi Lucky,

Generally, after INT, then read the status of parity.

If you read command everytime, it's fine if you handle all the error. i.e. readSPI() error for SPI bus fault.(If there is error, still needs INT to notify MCU)

Above situration from my understanding is to keep the data integrity.  The finial evaluation should be done by user side.

dw

0 Likes
LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

Hi,

We initially put read the status of parity in INT. But what I found is the situation I described above, only the first SPI can generate the INT signal, and the remaining SPIs cannot generate interrupts because the INTs are all low.

So it was later modified to: Every time the Write command is executed, a check is performed. But it's not clear if doing so complies with the functional safety documentation.

Do you have a reference demo that you can provide us with reference?

in addition,
According to the way you described above:
The machanism depands on the customer's need. Here is an example:

Send first command.

Check the ACK. (If error then resend)

Send second command.

Check the ACK. (If error then resend)
Can I understand that it is to let TC377 calculate the SPI data returned by 35584?
If the command received by 35584 is correct, but the SPI data returned by 35584 to TC377 has a parity error due to the interference of the SPI bus, then let TC377 send the same command once. Is this going to be a problem.

0 Likes
dw
Moderator
Moderator 10 likes given 500 replies posted 50 likes received
Moderator

Hi Lucky,

For demo project code please consult your local Infineon sales office of Infineon distributor representatives.

You can download SPI demo code from github, however please note that the function safety is not assured for the Infineon free iLLD driver. 

If the command received by 35584 is correct, but the SPI data returned by 35584 to TC377 has a parity error due to the interference of the SPI bus, then let TC377 send the same command once. Is this going to be a problem.

For this point, sendSPI() and receiveSPI() will get different parity error. First one is from 35584 INT to MCU, the second one is generated by MCU itself.

 

dw

0 Likes
LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

Hi,

Yes, for the method you said: if the SPI command received by 35584 is correct, but there is a problem when 35584 returns SPI data to TC377, causing TC377 to think it is wrong. So won't it cause TC377 to send the same SPI data to 35584 again?

Our SPI driver is normal.
What we really want to know is,
What is the retransmission mechanism officially recommended by Infineon?
If it is recommended to retransmit in NMI interrupt, how to handle the case of consecutive SPI command errors.

Is there a problem with the following processing mechanism if it is not handled in the NMI interrupt? :

After each write command is completed, a Read SPISF.PARE command is followed. If SPISF.PARE=1, a retransmission is performed immediately, and Clear SPISF.PARE is completed after the retransmission is completed. This allows each SPI command to be retransmitted after a parity error.

Is it reasonable to follow a Read command after each write command?

Concern: The above situation has nothing to do with the INT interrupt of 35584, so whether it does not meet the situation described in the functional safety document.

 

0 Likes
dw
Moderator
Moderator 10 likes given 500 replies posted 50 likes received
Moderator

Hi Lucky,

The INT and parity error bit features are provided to make data integrity, so the machanism should be designed by users following the functional safety.

And Infineon provided the demo code at github but just for a reference.

 

dw

0 Likes
LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

Hi,

The SPI_TLF_1_KIT_TC397_TFT demo of Github does not mention the retransmission mechanism.

If it is recommended to retransmit in NMI interrupt, how to handle the case of consecutive SPI command errors. The case shown in the figure below:

LuckyDu_0-1658313880320.png

Because the INT signal is only pulled low once, only the first frame is retransmitted, and the remaining SPI data cannot be retransmitted. Before the next frame of INT signal comes, I need to wait at least 400us.

LuckyDu_1-1658313972441.jpeg

LuckyDu_2-1658313980774.jpeg

 

 

 

0 Likes
dw
Moderator
Moderator 10 likes given 500 replies posted 50 likes received
Moderator

Hi Lucky,

There is no exact demo, but you could refer to:

https://forums.freertos.org/t/semaphore-and-spi-interuppt/5404

Please note:  Users should design their own machenism to fullfill functional safety requirement.

 

dw

0 Likes
LuckyDu
Level 1
5 replies posted 5 sign-ins First reply posted
Level 1

Hi, dw:

Thanks for your answer.
Regarding the SPI interrupt in your link above, it's not what I want.

Because of the hardware interrupt mechanism of 35584, the generated INT interrupt signal will be slow, causing us some doubts.

I'll try to find some information again.

0 Likes