MCZ33996 SPI Timing / Power Sequencing Issue

[VickyWang]

Dear NXP Technical Support Team

We are encountering an abnormal SPI behavior with the MCZ33996 in a dual power supply scenario and would like your technical guidance. Below is the detailed description of the issue and our questions.

Please refer to the attached oscilloscope waveform and schematic diagram for details.

Issue Description:
In our application, the MCU and the MCZ33996 are powered from two independent sources.
During a power cycling test of the MCU (while the MCZ33996 supply remains stable), we observed that the valve indicator light turns on unexpectedly. Measurement results indicate that the MCZ33996 is producing abnormal outputs.

Waveform analysis shows that when CS is high, the MCZ33996 appears to be reading data and driving outputs. This occurs while the MCU is in the process of powering down or powering up, during which it cannot actively control or read data.
When the MCU is operating normally, the MCZ33996 outputs behave correctly.

Captured waveform channel mapping:

• CH1: MCU 3.3 V (Yellow)

• CH2: NXP CS input (Green)

• CH3: NXP CLK input (Blue)

• CH4: NXP SI input (Red)

My  Questions:

1. RST Pin Source

   • Should the MCZ33996 RST pin share the same power source as the MCU, so that the device is automatically reset when the MCU powers down?

2. Need for RST in Software

   • Is it strictly necessary to issue a reset (RST) in software? The current customer’s view is that if the MCZ33996 side has a stable and continuous power supply, it should not require a reset. If implementing a reset in software is difficult, is it possible to avoid the issue purely through hardware measures?

3. Vendor Suggestions

   • Do you have any additional recommendations or best practices to ensure the MCZ33996 outputs remain disabled during MCU power cycling when the device itself remains powered?

   • Specifically, how can we avoid false SPI transactions or unintended outputs when the MCU IO pins are floating or in an undefined state during power-up or power-down?

We appreciate your feedback on whether this behavior is expected given the power sequencing, and your guidance on recommended hardware or firmware countermeasures

Attached  

Thanks

vicky 

[JozefKozon]

Dear Vicky,

1. RST Pin Source

   • Should the MCZ33996 RST pin share the same power source as the MCU, so that the device is automatically reset when the MCU powers down?

[A] Yes, this is correct. Please refer to the Figure 1. in the MC33996 datasheet. The RST pin should be driven by your MCU. If the MCU is powered down, the RST should be pulled low by your MCU. 

2. Need for RST in Software

• Is it strictly necessary to issue a reset (RST) in software? The current customer’s view is that if the MCZ33996 side has a stable and continuous power supply, it should not require a reset. If implementing a reset in software is difficult, is it possible to avoid the issue purely through hardware measures?

[A] If you don't want to reset the MCZ33996 during the MCU power down, while the MCZ33996 will be still powered, please use a weak pull-up resistor (e.g. 10k) from the RST pin to VPWR pin of the MCZ33996. Then the MCZ33996 will not be reset when MCU will be powered down, but can still be reset if requested by your MCU. 

3. Vendor Suggestions

• Do you have any additional recommendations or best practices to ensure the MCZ33996 outputs remain disabled during MCU power cycling when the device itself remains powered?

• Specifically, how can we avoid false SPI transactions or unintended outputs when the MCU IO pins are floating or in an undefined state during power-up or power-down?

[A] Please refer to the Figure 1. The MCU and the MCZ33996 logic circuit for SPI sending message must be powered from the same source, so the SO interface will be disabled when the MCU will not be powered. 

With Best Regards,

Jozef

[VickyWang · Accepted solution]

Hi Jozef ,
thanks for your great support
we solved the issue last week .