Recently a problem has been troubling me. In most times, W5300 is able to work properly, but after the system reset, W5300 Led connected to Link LED signal and speed LED signal blink with freq. ~ 1 Hz , not working. After power off or another system reset W5300 works. In do a software reset in my w5300 init. The reset button is also connected to the reset pin on the w5300 chip. What can cause such a behavior?Thank you!
Are you sure garantee the time 2us of reset low, and the PLOCK time 10ms after reset high?
W5300 reset time refer to W5300 datasheet.
I don’t know the another reset what you said. You mean it software reset?
Thanks for your fast answer.
The another reset are the reset pins on my print. These are connected to the reset pin of the W5300. The problem occurs also when i make the reset pin low for 1 second or when i power off the print for one minute. When power on I initialize the chip by first make the MR = (1 << 7); reset bit high. Afther that I wait for 300ms. The problem is difficult because it occurs not every startup cycle. Can someone please help?
Thanks in advance.
Link LED blink is caused by PHY failed auto-negotiation processing.
How many do you use the reset source of W5300?
According to what you said, It may be two sources as reset. am I right?
Can I show your schematics?
Thanks for your answer. I e-mailed you the schematics. The reset pin of the W5300 is connected to the reset pin of the microcontroller and the external reset pins on the print.
So I have a hardware reset and in my W5300_init() I use one software reset. The W5300 is used for a PLC(Programmable logic controller) controller. The PLC controller controls a packaging machine. This machine must be powered on and off without any problems.
The PLC controller is in the developing phase. So I use the hardware reset pins +/- 10 times a day. About 1 in the 20 resets the W5300 is not starting and the link led blinks with a frequency of 1 Hz.
Thanks in advance.
As I show your schematics, You shoud be connect the reset to VDD with pull-up register.
Congratulations. I had the same problem with several WizWeb200 modules, which were already patched to allow the ATmega128 to operate the W5300 /RST line by GPIO (using an RC combination on /RST is a really stupid idea if you have slowly rising power supply).
Nevertheless, especially after a system reset one module or the other might end up in such a state… linkup, linkdown, linkup, linkdown… forever. Usually it happens after a remote firmware update, but not limited to that (main system is still operational, but TCP/IP access is blocked, which will lead the main system to notify me as some nodes did disappear).
According to Wiznet this problem is not known, and they never heard of it… several requests to WizNet support didn’t give any satisfying answer (it is, of course, a really hard to track down problem, as it cant be easily reproduced).
I haven’t found a real fix for it. Seems to me that the W5300 PLL screws up and doesnt operate properly, so the whole chip is locked in a really weird state.
My best fix (so far) is to monitor the LINK signal (from LNKLED, as there is no PHY status register). In case too many linkup/linkdown changes per minute are monitored, I do a full system restart and hope the best for it.
I think users of W5300 need to live with that feature.
It’s not clear in the w5100 or w5200 data sheets if PLOCK also applies to software reset? I can do a test to find out, but does anyone know? Same question for w5500.
If this bit is ‘1’, internal register will be initialized. It will be automatically cleared after reset.[/quote]
The indication of the software reset completion is RST bit becoming 0. No need to wait for 10, 150 ms or whatever.
Regarding initial problem with reset. Three things I would consider:
- Quality of power during reset and after it;
- Quality of clock crystal and layout of the related conductors;
- Quality of reset signal (not only its duration, but also noise during its operation and its transitions between logical levels).
I have been working with these microchips(W5300, W5200) for many years. These crystals are very critical to temperature and soldering time. I think Wiznet knows about this problem. If you overheat the microcircuit during soldering, the microcircuit starts only if it heats up. The problem is solved only by replacing the chip. In some parties to behave in this way 10% of the chips. The problem is that you never know at what temperature the modules are soldered.
How to detect a bad chip:
- Сool the chip to 16 -18 degrees
- Make 5-7 startups(1-2 sec.). If in one of the cycles there is no connection, the chip is not valid.
- If the chip does not start, it can’t be put into a working state without turning off the power. (Reset has no effect).
- After warming up the chip to 29-30 degrees, it will work without problems.
- Chip replacement required.
My empirical studies show very similar findings. I had to replace 30 chips recently because I was hand soldering them at 380 C. Now I solder at 305 C. Thanks for the way to identify bad chip!
Евгений, я Вам советую использовать пасту Sn42, Be 58 и паять эти чипы не более 225 град.
Иначе будут постоянные проблемы со стартом. Вы работали с чипом W5500 промышленно? Я только начинаю переход н эти чипы. Не хотелось бы иметь эти проблемы.
It looks like we have the same problem in our production.
We use W5300 chips in production. It seems that about 5%-10% of boards has issue with W5300.
Issue is hard to detect because it appears only sometimes.
Corrupted units has irregular connectivity issue. Approximately once per 10-50 connection link is not established. The problem goes away as soon as we replace W5300 manually.
We would keep it as it is, but we have big array of devices connected through W5300. Each time we turn array on, some random devices are not linked. We have to replace chip or board to fix the problem. Once chip is replaced, problem never comes again.
Every corrupted unit has approximately stable issue rate:
For example one corrupted unit can have connectivity issue once per 5-7 times
another corrupted unit could have the same issue once per 15-20 times
Functional boards were tested for connections more then 200 times without any errors.
We put a lot of time to research an issue and it still seems to be out of control. So we just decided to replace chip on 5% of the boards manually.
But last batch of boards, we got from manufacturer has much more corrupted boards (about 30%) with the same issue.
We might go to different Ethernet solution in next revisions if we can not find how to fix that.