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?
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.
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.
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)
Thanks Nagarajan.
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.
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)…
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?