GD3162 gate driver

[Akshat_VE02376]

Hi NXP, would really appreciate if you clarify the below mentioned queries:

Q1

Exact cause of SPIERR_Flt ? According to ds, SPIERR occurs in two scenarios:  CASE 1:  CRC or Framing error.  CASE 2: SPI message delay is too brief. (<19us). I have ruled out the first case since we are able to write successfully the appropriate values to the registers we require without any CRC issues. Considering the 2nd case, we tried introducing significant delays after each sending each 24-bit frames but still the SPIERR tends to occur for some gate drivers sporadically.

Q2,

I need proper root-cause for RTMON fault which is sporadically occurring for some GD's

[JozefKozon]

Dear Akshat,

please refer to a note in the Table 62. and to the section 11.8 in the GD3162 full datasheet. It says, that the RTMON_FLT is valid only if the RTMON_CFG bit is set to 0. Please confirm when the RTMON_FLTM = 1 occurs, is the RTMON_CFG = 0?

With Best Regards,

Jozef

[Akshat_VE02376]

Yes, RTMON is zero in MODE2 register. I want to know the exact reason behind that fault and how can it be rectified. Also please tell me about SPIERR which I have asked

[JozefKozon]

Hi Akshat,

I have contacted an application team for your questions. Please see their answer below.

DESCRIPTION

Regarding SPIERR: there are 3 possible causes: invalid CRC, too small interframe delay, and invalid number of SCLK edges within a frame. For the last check, the GD verifies at CSB rising edge that there was a multiple of 24 SCLK edges during the time where CSB was low. If not, a SPIERR will appear.

You mention that this SPIERR fault is intermittent. Does it occur systematically on the same frame/data? Otherwise this could be due to noise : a glitch on SCLK could cause invalid multiple of 24, glitch on MOSI could cause invalid CRC.

Regarding RTMON_FLT: this fault is triggered when the state of the Gate (seen at AMC pin) does not match the state of the PWM input, after a comparison delay RTMON_DLY. This delay must be programmed by customer to ensure that due to the RC Gate charge/discharge time constant, the comparison occurs when the gate has finished transitionning. To be more precise, the delay should be long enough to ensure the gate is within 1V of the supply rails for all gate strength combinations.

To troubleshoot, customer can look at the gate rise/fall times just before RTMON_FLT is triggered, and compare with RTMON_DLY setting.

With Best Regards,

Jozef

[Akshat_VE02376]

But if the number of clock cycles between CS low to high is not a multiple of 24 then in that case the write command will be ignored right (According to DS)? But I'm able to write to the registers and read back the written values. In this case what could be the possible reason. If it is due to interframe delay you have mentioned, then I assume that you mean 24bit frame. And I have already tried giving significant delays still the fault latches. !

[JozefKozon]

Hi Akshat,

please see below an answer from the application engineer I have just received. 

DESCRIPTION

An invalid multiple of SCLK pulses, or invalid CRC will indeed lead to rejection of the SPI frame contents by the GD, and default SPI response. However, remember that there is a 1 frame delay between request on MOSI and answer on MISO. So the actual faulty frame might be located beforehand.

To further understand your issue, can you please capture the instant where INTB goes low due to SPIERR, as well as the preceding 2-3 SPI frames + decoding? If you use Tektronix oscilloscopes you can even share a .tss file with us so we can further look into this capture.

As an additional check, you can also verify that the SPI signals follow the required SPI timings (Table 12. of the datasheet).

With Best Regards,

Jozef