W7500P Cold booting failure. POR operation error

I Read Erratum 5 Cold Booting Failure of W7500x Errata Sheet. I am using UM809 (typical voltage 2.93 Volts.) 3-Pin Microprocessor Reset Circuits. But this did not give a 100% result of a successful start of the W7500P processor.
I use these processors for mass production, and about 5% of processors have a cold start error, even when using “The best solution is to add POR(Power On Reset) chip”

My observations have shown that there remains a dependence on different phase power source supplied to peripheral pin before Power on.
There is also a dependence on a prolonged increase in the supply voltage to the operating voltage.

  1. The first case
    In my device, the input voltage is 12 Volts, for the power supply of the W7500P I use 340kHz Synchronous Step-Down Converter 12V-to 3.3V.
    I also need to control the input voltage of 12 volts. I do not need high measurement accuracy, so I used a resistive divider and a protective zener diode 3.3 before entering the W7500P ADC. When observing devices that had a bad cold start, I noticed that if you lower the voltage at the input of the ADC from a 12 Volt power supply with a different phase, then this helps and the cold start is successful.

Previously, I used a resistive divider coefficient of 1 to 8. At the same time, the input voltage to the ADC input approximately corresponded to 1.5 Volts. I increased the division coefficient of the resistive divider and was able to achieve a stable cold start only at an input voltage of 0.3 Volts. But this greatly impairs the accuracy of calculating the input voltage.

  1. The second case.
    In another case, I have a device that is also powered by 12 Volts, but the W7500P is powered by a 3.3V LDO ( LD1117S33TR - STM). They also have a dependence on the input voltage, but I already know about it and lowered the voltage to 0.3 Volts (or even removed it completely for the experiment).
    But in this case, I have a dependence on the rate of rise of the input voltage. Since the LDO, unlike the DC-DC converter, does not have a turn-on delay, the input voltage of 3.3 Volts increases smoothly, repeating the smooth increase in the output voltage of 12 Volts. With a smooth increase in voltage of 3.3V (from 0 volts to 3.3 volts more than 5ms), there is also a cold start error.

As far as I understand, the error is related to the integrated reset (POR) circuit. Since in case of a cold start error, there is no reaction to the RSTn pin.

First, not clear why you think your problem is caused by the POR and Errata 5 description is the one causing the issue.
Second, the errata is relatively clear on what causes the problem. Application of the power to the peripheral chip before power supply pins, and slow rise of the power supply voltage (> 20 ms). All these conditions can be inspected using scope, but you did not attach any pics as proofs.
What reset supervisor is doing is holding chip in hard reset until power raises to 2.93 V (typ) and performs it reliably without noise and false-starts with minimum reset pulse width of 120 ms after power reaches 2.93 V.

If you prove you do this way with your current circuit, the only way is to remove conditions described in errata 5 - remove connection to peripheral pins and ensure power raises within 20 ms - and see if problem persists. If it does, errata 5 does not apply for your case and there’s an issue somewhere else.

I have the following data, I apply reset supervisor see how it working.

I see at least 150 milliseconds of delay is holding chip in hard reset

If I supply power from a source that provides a smooth increase in voltage

The rise time is about 10ms Cold Start does not happen

The blue line is one control pin of the processor, which should have a meander with a period of about 20ms.

The other power supply has a very steep form of voltage increase.

The voltage rise time is about 0.1 ms

In this case, I see a cold start, I see a meander on the blue chart.

Why do I think this problem is related is caused by the POR? I looked at the CRG diagram

According to this, the processor start should occur if the RSTn pin has a high logical level and the POR has a high logical level. But after 150ms the reset circuit releases the RSTn pin, the start does not occur.
If I manually close the RSTn pin again using the button, the launch does not occur.

I observe this behavior in about 5% of all devices that we make. In the remaining 95% of cases, such a problem is not observed.
According to the reasons that lead to this behavior, I conclude that this problem is similar to Errata 5 description

IMHO this is an indication of wider issue. If chip does not start on power on, hardware reset must clear this situation. If it does not, then the condition is called lockup.

Errata 5 states power rise < 20 ms and potential > 1V on the I/O pins. For this case, can you disconnect all peripheral pins and see it is starts?

That’s why I think issue is similar, but different. Bringing reset pin low must reset the chip even if internal POR did not reset it, in your case it does not happen.

Can you confirm that same board of these 5% may start or not start, and the behavior is steady for specific condition? Is there no physical difference between remaining 95% which always start - internally on the board and externally to the board?

Thank you for your answers.
Yes, I checked, I physically disconnected all peripheral circuits and checked, it doesn’t help.

Yes, I confirm that the same board of these 5% starts if the voltage increases quickly and does not start if the voltage increases slowly. The behavior is stable and repeatable under the same conditions.
All boards (much more than 1000 pieces) are assembled automatically using Samsung Hanhwa SM482, soldering is carried out in a conveyor 5 zone furnace of convection reflow. There is no physical difference.

Dear Eugeny, can you explain it to me in more detail?
What is a condition called lockup ?

As far as I understand, you do not belong to the Wiznet engineering team.
You use these processors as well as I do, but you, unlike me, have a lot of experience in this.
I’m wondering how long can I expect a response from the WizNet engineering team?

Yes, I am not an employee of the WIZnet, and I used to use W5100.
Lock up is the condition when device is stuck in some condition and can’t recover itself or be recovered from it, only power cycle helps. As I know this condition is usually exhibited by the excessive current being consumed by the device, and thus excessive device heating.
I recommend you emailing WIZnet support for (1) quicker problem resolution and (2) errata 5 is slightly unclear and inconsistent in its text, we need clarification for it.

Do you mean I have to write an e-mail to WizNet support?
I thought this forum was the way to contact WizNet tech support.
Now I’ll look for an email address to contact technical support. If it’s not too much trouble, can you tell me the correct address?

Locations. Point them to this thread.

Thank you, I wrote. I will be waiting for a response from support

In Reference Manual (Version 1.1.2 ) I found this:

6 System configuration controller (SYSCFG)
Main purposes of the system configuration controller are the following
 Control of the memory remap feature
 The ability to enable an automatic reset if the system locks up
 Information about the cause of the last reset

I am particularly interested in the second function - The ability to enable an automatic reset if the system locks up.
But, that’s it. No more information. Ahh

Tech support has not responded.
I am still continuing to study this problem on my own. Now that I have started to understand the reasons that cause this problem, I have found a much higher failure rate. Now the number of boards on which processors behave unpredictably increases to 20%
I found an old one W7500P Reference Manual (Version 1.0.3). In an old document I found a detailed description of the registers RESETOP and RSTINFO.

[2:0] RSTINFO – Information register about the cause of the last reset.
These bits are written by S/W; write 1 to each bit to clear
[0] : if 1, SYSRESETREQ caused the reset.
[1] : if 1, Watchdog caused the reset.
[2] : if 1, processor LOCKUP caused the reset.

I output these values to UART debugging. Now when the processor starts, I can see the value of RSTINFO. Every time, even after a failed start, I get the value:
[0] : if 1, SYSRESETREQ caused the reset.
That is, according to RST INFO, it is not processor LOCKUP caused the reset