We have a few instances of W7500P-S2E crashing during the operating. The chip was working fine for a few days, then lost its connection. Neither from Ethernet side (port 5000 and 50001) nor from serial port side can access the chip. The only way to bring the connection back is using Wiznet ISP tool to reload the code and then use WizMAC tool to set the IP.
Would you have any suggestion of debugging this issue?
It’s a strange symptom.
Flash memory inside W7500P seems to be damaged during operation.
Is the power supply stable? Or is there an external electrical shock?
This was tested in the lab environment. It happened on 3, out of ~30, W7500P we were using so far. Our circuit is very similar to your WIZ750SR.
Is there a way to reset the W7500P to the factory default instead of reloading the code?
Do you have any update of this? Will the operation such as data streaming cause this issue? Two chips show data clog issue during streaming, but the issue of one chip went away after reflash the code.
If sending our schematic to you, could you help us to review the design for any mistake?
I’m sorry for late reply.
If you send me your schematic and PCB design file so I can check it,
I will review it.
If the W7500P does not work after resetting, it is believed that a fatal problem has occurred.
I have a very similar issue. 300 boards, assembled with W7500-S2E with preprogrammed firmware 1.1.0 and all updated to 1.2.4, were tested successfully and then stocked in our warehouse for a couple of weeks. Then, 20 boards were turned on for testing. A couple of them were not communicating to any software (including ConfigTool)… dead except the blinking leds on the RJ45 plug. I’m very worried.
Thank you very much for the help. Here are the schematic and the PCB package for your reference.
81-0345 Rev2_20191024.pdf (132 KB)
Gerber.zip (318 KB)
We do face this issue of memory corruption. Only doing ISP solves in 4 units.
Hi Cosmos and Nagarajan.
I found that two of my not working units had the first 256 bytes of the Flash memory erased (all FF), compared to a working one. Once reprogrammed by SWD connection, they resumed working normally.
One thing I have in common with Cosmos (thanks to sharing the schematic) is the RSTN pin 26 of MCU floating. We have a pullup resistor in the schematic, but it was not mounted (missing in the BOM/PKP).
Can this floating RSTN pin cause Flash corruption? Nagarajan, do you have floating RSTN pin too?
Below the bad and good Flash memory files, read back by SWD. wiz_bad.bin (128 KB) wiz_good.bin (128 KB)
And please, Wiznet team, help us!
Please find our circuit.
SCHEMATIC1 _SERIAL-ETHERNET.pdf (30.6 KB)
RST is not floating.
How it happened to you to corrupt the Flash?
It looks like the bootloader (not the latest version, but all the previous), any time the MCU is started, the first 256 bytes of Flash are deleted and then written with the IRQ table of the application. If something goes wrong (i.e. supply glitch that executes up to the Flash delete, and no more), the Flash is not rewritten and the MCU is dead. We may be wrong with source code understanding, but this is what we understood. And it explains why the first 256 bytes gets corrupted.
Thank you very much for sharing this information. Would you know the latest bootloader version number and the release date?
I got the W7500P-S2E that Wiznet ships with bootloader 1.1.1.
The IRQ table delete and rewrite thing was removed, according to your git repository, in version 1.3.0, the 18th of November, 2019.
The Copy_Interrupt_VectorTable function, first erases the first 256 bytes of Flash, then it copies the IRQ from application to the just erased sector.
- Flash memory will be destroyed after 10000 cycles
- corruption occurs
A savvy developer would have compared the current IRQ with the APP one, erasing and rewriting only if any difference was found (i.e. after a FW update)…
Hi Wiznet Team,
Could you give us some comments or suggestions regarding to this? Should we reflash all our W7500P to the latest version (V1.3.3?). Or just keep it as V1.2.4 Stable?