UCC5880-Q1: SPI Fault Observed on power cycle for GDIC(UCC5880-Q1)

Hi Lakshmi,

Thanks for the contact and sharing all the information.

From first capture, looks like six gate drivers all reported SPI_FAULT, it is possibly that the SPI commands are invalid. Do you  

• May you share what kind SPI mode is used, Independent, daisy chain, or address mode?
• Since SPI_FAULT reported on all gate driver, it is suspected that the SPI signals are invalid. Please refer to Table 6-4, the invalid SPI means: a) SPI clock error (more or less 16 clocks received), b) unrecognized SPI command, c) SPI CRC incorrect (rule out as CRC is not used). 
• It is recommended to measure NFLT1, NCS, CLK, SDI, (SDO as optional) and use NFLT1 pull low as a trigger to measure NCS, CLK, SDI waveforms through probes or digital analyzer when SPI_FAULT is reported. The SPI command right before the SPI_FAULT should be the invalid SPI command. 
• Could you share ACT1[SPI_ACT] setting?
• Could you please clarify: you read fault register whenever sequence.9 complete or you find a NFLT1 pull low then you read the fault register? The invalid SPI command could happens in the middle of sequences if you only check the fault after sequence.9.

Regarding SPI_FAULT cannot be cleared, it is not expected unless the clear_fault command is an invalid SPI command. Could you please share what exact SPI commands that you send to clear the fault?

Regarding the third bullet-point in additional notes: SPI function is not disabled after SPI_FAULT, so read back register value is expected.  

Regards,

Luowei

hi

Hi Wen,  

       Please find my answers to the questions highlighted in yellow. 

May you share what kind SPI mode is used, Independent, daisy chain, or address mode  : Independent peripheral mode .

Since SPI_FAULT reported on all gate driver, it is suspected that the SPI signals are invalid. Please refer to Table 6-4, the invalid SPI means: a) SPI clock error (more or less 16 clocks received), b) unrecognized SPI command, c) SPI CRC incorrect (rule out as CRC is not used) : Logic analyzer trace is attached in ticket below. Also, first command sent over the BUS is NO OPERATION and then we send Identification register requested. We can observe 16 clock pulses from frame.

It is recommended to measure NFLT1, NCS, CLK, SDI, (SDO as optional) and use NFLT1 pull low as a trigger to measure NCS, CLK, SDI waveforms through probes or digital analyzer when SPI_FAULT is reported. The SPI command right before the SPI_FAULT should be the invalid SPI command: Logic analyzer trace is attached in ticket below. The first command sent over the Bus is NO OPERATION to align the SPI response pipeline. 

Could you share ACT1[SPI_ACT] setting:   The value of ACT1 register 0xF328

 Fig 1 :  ACT1 registers value.

Fig 2 : Read Fault registers after step 9(active mode)

Could you please clarify: you read fault register whenever sequence.9 complete or you find a NFLT1 pull low then you read the fault register? The invalid SPI command could happen in the middle of sequences if you only check the fault after sequence.9: Yes, I read the fault registers after sequence 9 is complete (active mode).  

logic_analyzerlogs_spi_03_02_2026.docxSPI Logs with and without faults.zipSPI Logs_nospifault.zip

Logic analyzer data.

Please let me know if there are any further queries 

Thanks, and Regards,  

Satish Kumar 

Hi Satish,

Thanks for sharing the information. Based on the shared setting, please see my feedback below.

1. In Independent peripheral mode, nCS of each device is individually controlled. When one command sending to a single device is wrong, it should not cause SPI_FAULT on all device. It is suspected that one command is not sending correctly to all devices.

2. Based on ACT1[SPI_ACT], when SPI_FAULT reported, NFLT2 should pull low. Could you monitor the NFLT2 and use NFLT2's falling edge as a trigger to check which SPI command ahead of this falling edge is invalid.

3. As mentioned, the fault register is read after sequence 9 is complete. As SPI_FAULT would not stop the SPI commands, any invalid SPI command before sequence 9 could create the SPI_FAULT. It is recommend to find the invalid SPI command by using NFLT2's falling edge.

4. One extra possible way to find the invalid command is to add "read fault register" command after each SPI command to find where the SPI_FAULT reported instead of monitoring NFLT2.

Regards,

Luowei 

Hi Wen, 

Please find my reply highlighted in yellow:  

1. In Independent peripheral mode, nCS of each device is individually controlled. When one command sending to a single device is wrong, it should not cause SPI_FAULT on all devices. It is suspected that one command is not sending correctly to all devices.  I agree to your statement but why is SPI fault not seen after a flash or in target reset done using the debugger. If one command is incorrect then SPI fault should always be set. 

2. Based on ACT1[SPI_ACT], when SPI_FAULT reported, NFLT2 should pull low. Could you monitor the NFLT2 and use NFLT2's falling edge as a trigger to check which SPI command ahead of this falling edge is invalid. As of now we are only considering NFLT2 as a warning and depending on register status. We don't have pin connected in PCB to get NFLT2 data. But based on ACT1 configuration if SPI fault is set NFLT2 is supposed to be low.

3.  As mentioned, the fault register is read after sequence 9 is complete. As SPI_FAULT would not stop the SPI commands, any invalid SPI command before sequence 9 could create the SPI_FAULT. It is recommend finding the invalid SPI command by using NFLT2's falling edge. I agree with you, I tried to clear the SPI fault using the Ctrl 1 register using the software using control1 software but unable to clear it. How come when i toggle any one of GD0, Gd1 and Gd2 pins, the SPI fault gets cleared? I am curious to know what relation GDx pins have with SPI fault.   

Fig 1: Using the Control1 register we are using CLR_FAULT. 

One extra possible way to find the invalid command is to add "read fault register" command after each SPI command to find where the SPI_FAULT reported instead of monitoring NFLT2 : I would like to reiterate my point given in point 1 , If there is  a invalid command, SPI fault should always be seen , Why is it seen after abrupt power cycle and why it disappears after flash or in target reset done using the debugger. 

Could you please schedule a meeting with us ASAP or we can send a meeting invite based on the available time. 

Thanks, and Regards,  

Satish Kumar 

Hi Satish,

Could you please help clarify on "abrupt power cycle and why it disappears after flash or in target reset done using the debugger"? 

And could you please share when do you flash or reset in the sequences? Is it before sequence 1, within these 9 sequences, or after sequence 9?

We have seen, in some cases, CS pin pull low when MCU power cycle. This CS pull low will be received at the gate driver side without any clock or some pulses (less than 16) on clocks that caused SPI_FAULT.

Regarding the conditions of setting SPI_ACT to NFLT2, here are some recommendations for further debug where the SPI_FAULT is reported.

• Add "read FAULT2 or STATUS register" command after each Sequence to find where the SPI_FAULT reported instead of monitoring NFLT2.
• Set SPI_ACT to NFLT1 and use NFLT1 as the trigger to find where the SPI_FAULT is reported.

SPI CONTROL1[CLR_FAULT] command should do the same job as all GDx pin pull high regarding clearing SPI_FAULT. It is recommend to check the CLR_FAULT command. One note CLR_SPI_CRC is not needed to clear the SPI_FAULT. Here are some recommendations

• Use digital analyzer to check the CLR_FAULT command.
• Set other fault (such as UVLO1_FAULT, etc.) instead of SPI_FAULT and use CLR_FAULT command to clear it to see if the command is valid or not. 

Regards,

Luowei

Hi Wen, 

Could you please help clarify on "abrupt power cycle and why it disappears after flash or in target reset done using the debugger"?  : We would like to better understand the root cause of the abrupt behavior, as that was the main reason for raising the ticket.  

And could you please share when do you flash or reset in the sequences? Is it before sequence 1, within these 9 sequences, or after sequence 9 : Reset I do in the config state , before going to sequence 9. I have also tried doing reset using SPI command after sequence 9 but behavior doesn't change. We will try it again. The question is , why are we trying to clear the fault registers in active mode , Even though control registers can be changed in active mode, is it not a good practice to try to clear the fault in config mode itself. 

We have seen, in some cases, CS pin pulls low when MCU power cycle. This CS pull low will be received at the gate driver side without any clock or some pulses (less than 16) on clocks that caused SPI_FAULT: We did not observe any fault conditions during the event, and logic analyzer trace are attached in the ticket below.

Case 1 : SPI fault seen after a power cycle 

Fig1 : SPI Fault seen after a power cycle. 

Case 2 : SPI fault seen after a power cycle and clear command used immediately and the spi fault is still seen. 

Fig 2: SPI Clear command 

Fig 2.1: SPI fault seen after clear command. logs_3_6.zip

Please find the logs attached in the ticket below.

Thanks and Regards, 

Saish Kumar 

Hi Satish,

Thanks for sharing these results. I will set up the digital analyzer on my side to review the shared data internally and share feedback by Tuesday.

Regarding clearing faults in CONFIGURATION and ACTIVE states, states would not influence the CLEAR_FAULT SPI command and the command is expected to clear faults when the fault conditions are removed. 

Regards,

Luowei

Hi Satish,

After a review within team, please check two suspects with two recommended actions.

• CLEAR_FAULT commands could be invalid that is unable to clear faults.
  • To check if the CLEAR_FAULT SPI command is valid or not, could you resetting faults by GD0/1/2 (setting them to 111) between 0x0542 and 0x0C15? If the SPI_FAULT is clear and didn't pull up, the CLEAR_FAULT command can be confirmed good.
• The individual dependent SPI mode is suspected created the SPI_FAULT as they are sharing the SDI, SDO, CLK.
  • Could you please only sending SPI command to a single device (ex. LS_U only) and check if SPI_FAULT is reported or not? That help confirm if the SPI configuration setup is good or not.

Would you please accept my friendship request on E2E? We can set up a meeting to go though all information. Please help check following two questions in the meantime.

• For case 2, what is your power cycle procedure? Do you power cycle VCC1 only or both VCC1 and VCC2?
• When you set the configuration register in CONFIG mode, do you read configuration registers back to confirm the writing is successful?

Regards,

Luowei

Hi Luowei,

Thank for detailed information. Regret for delay in response because we are busy in one of software delivery. 

We will be available from mid of next week. Let me know your availability for discussion?

Best Regards,

Prasanna

Hi Lakshmi,

Good to hear back from you. The mid of next week work for me. I sent you a friendship request on E2E, could you accept it? We can exchange the email and set up the meeting next week.

Regards,

Luowei

Hi Luowei,

Didn't receive any friend requests on E2E. I verified in Friendship Requests / Connection Requests profile location. guide me where to verify if this is correct location.

Best Regards,

Prasanna

Hi Lakshmi,

You can click my name tag and it will guide you to my profile. Please click "+ Connect" and select add friendship or either accept it. Then we can send private chat on E2E.

Regards,

Luowei 

Hi Luowei , got it.Accepted your friend request. let me know if you have received.

Regards,

Prasanna

Hi Luowei, showing   below 

accepted you're requested but still not shows in friend directory. what is this meaning, whether it is accepted or InProgress

Best Regards,

Prasanna