#Initial sequence timing problem in GD3162??

[Mooang]

Hi, I am using inverter which using s32k396 mcu bga type and GD3162.

I have question about GD3162 initial sequence timing.

I’m using an S32K396 MCU with GD3162 gate drivers in an automotive inverter.
We have 6 GD3162 devices in total, configured as two daisy-chain groups (TOP 3 devices and BOTTOM 3 devices).

I’ve found a strange behavior regarding the GD3162 initialization sequence depending on how the system is powered up.

When I power on the inverter normally and control it through CAN only, the U-phase BOTTOM gate driver does not switch at all, while the other 5 channels work normally.

But when I power on the system and then load the ELF file through Trace32 using a CMM script, everything works perfectly — all 6 GD3162 devices switch correctly.
So there is clearly some difference between “normal power-up + CAN control” vs “Trace32 flash + run”.

In my software, the initialization part that controls the GD3162 looks like this:

Dio_WriteChannel(DioConf_DioChannel_DioChannel_3_GD_LS_PowerCon, 1); // This enables the 5V supply for GD3162 VDD

CDD_Gd3162_OsifSystemTimeDelay(100);

CDD_Gd3162_InitDriver(NULL_PTR);

CDD_Gd3162_OsifSystemTimeDelay(2000);

CDD_Gd3162_RequestReset();
CDD_Gd3162_OsifSystemTimeDelay(2000);

CDD_Gd3162_WriteRegister(CDD_GD3162_MAX_DEVICE_CONFIGS, GD316X_MODE2_ADDR8, DataCheck); // config enable
CDD_Gd3162_WriteRegister(CDD_GD3162_MAX_DEVICE_CONFIGS, GD316X_MODE2_ADDR8, DataCheck1);
CDD_Gd3162_WriteRegister(CDD_GD3162_MAX_DEVICE_CONFIGS, GD316X_CONFIG5_ADDR8, DataCheck8);

CDD_Gd3162_WriteRegister(CDD_GD3162_MAX_DEVICE_CONFIGS, GD316X_MODE2_ADDR8, DataCheck2); // config disable

What’s interesting is that if I slightly adjust the OsifSystemTimeDelay values in this sequence, then even with a normal power-up (no Trace32), all 6 gate drivers start working correctly.
So the problem seems to be strongly related to the timing of GD3162 power-up, reset, and configuration in the daisy-chain.

There is another issue as well:
During a dynamometer test, the inverter starts switching normally, but after some load is applied, the U-phase BOTTOM suddenly stops switching (I’m assuming this based on the 12V supply current drop and the motor sound changing). A fault is triggered at the same time.
But again, if I start the system via Trace32 (flash the ELF using the CMM file and run), I don’t see this issue at all — the inverter runs normally under load.

So both problems disappear when the system is started via Trace32, which makes me believe that Trace32’s initialization process (MCU halted during flash loading, delayed start-up, etc.) causes the GD3162 daisy-chain to initialize correctly, while a normal fast power-up does not.

I want to ask about the correct GD3162 initialization timing, especially in daisy-chain mode.
Specifically:

• Required delay after enabling VDD or bias supply

• Required delay before sending the first SPI command

• Recommended delay after CDD_Gd3162_RequestReset()

• Any timing constraints for multiple GD3162s in a daisy chain (e.g., all devices must finish POR before first communication)

If the GD3162 does not receive the configuration at the correct timing, is it possible for only one device (like the U-phase bottom driver) to fail to enable or to drop out later under load?

And is it expected that starting the MCU “too quickly” after power-up could cause SPI initialization to happen while some GD3162 devices are still in UVLO/POR state?

If there is any application note or example sequence showing the recommended initialization timing for GD3162 in daisy-chain configuration, please share it.

Is there any timing problem in my code above?

Thanks.

[Mooang · Accepted solution]

I solved it.

Unmatched timing of Voltage supply cause this problem.

I am using S32ds.
In my code, before running main code, start up code run first.

I noticed that when running my Trace32 .cmm script, the MCU starts executing the firmware only after the inverter has already been powered on for a sufficient amount of time.
Because of this, the power-up and voltage-stabilization timing seems to be much more stable when the debugger is attached.

To replicate the same behavior during a normal standalone boot, I added a small delay in the startup code so that the system waits a bit before entering the main() function.
After adding this delay, the issue was resolved.