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.
"

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.

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?

I am developing a solenoid controller board using the TLE92464ED and am having problems getting the chip to stay in mission mode. I have configured the chip as follows:

• Disabled Clock WD, SPI WD, supply tests. Enable 3.3V IO and CRC checking in GLOBAL_CONFIG.
• Cleared any errors present from reset in GLOBAL_DIAG0/1/2 reg.
• Configured the channel with solenoid attached to use ICC in MODE register and changed the slew rate to 1v/uS in the CH_Config register.

After setting up as described above I check the FB_STAT register and see only OLSG_WARNx_CHK_NOK warnings on all channels which I believe is expected since the channel has not been enabled yet. Next I set the chip to be in mission mode and then enable ch0 (solenoid attached). The chip successfully transitions to mission mode and shows the channel is enabled and will stay in this configuration enabled in mission mode. If I now change the value in the SETPOINT register to a non-zero value I can see a short voltage pulse and then the chip immediately goes back into setup mode and ch0 is disabled.

Am I missing something in the configuration that is causing this behavior? I hope someone will be able to point me in the right direction.

I have checked the hardware side and can measure the resistance of the coil across the input leads.