Unable to Flash W7500P, Write Protected
MCU & Boards
Attachments
-
bootloader.h
-
sys_init.c
-
bootloader.c
-
sys_init.c
-
main.c
- C/C++
- W7500P
No replies yet. Be the first to reply.
Join the discussion.
RE: Unable to Flash W7500P, Write Protected
by Grace_Koo WIZnet ·
Hi,
Good news first: your chip is not bricked, and your firmware could not have locked it.
ERAS CHIPreturning0proves the code flash still erases fine, and the lock information sits in the read-only Information block, which no IAP command can touch.Two quick facts to clear up what you saw:
7means Write Lock Protected, andC000000F FFFFFFFFafter every reset is normal — FLOCKR0/FLOCKR1 are volatile and the device always enters ISP mode fully locked, so the unlock has to be redone after every reset and the erase/program must happen in that same session.Here is what to do.
1. Check two settings in the ISP tool
LOCK PROGwith those values before erasing — so if they are left ticked, the chip is re-locked and the erase returns 7.ERAS CHIP), not "Erase Data Block All Code Block" (=ERAS MASS).ERAS MASSalso targets the two data sectors and is not needed for firmware.Also note the "Download Complete" popup is shown unconditionally — the tool does not check the XMODEM result — so it is not proof the write succeeded.
2. If that does not fix it, run this manually
From a plain terminal, in one session with no reset in between:
The first
DUMPshould read back allFF; the second should show your vector table. That tells us whether the flash is refusing the data, or whether it takes the data and the app still doesn't start. (IfXPRGrejects the address, try10000000— the app note uses that alias for code flash in boot mode.)3. If the second DUMP looks correct but there is still no UART output
In your
bootloader.cthe magic check is commented out:Boot_Entrytherefore jumps tohdr->entryunconditionally. If the app area is blank that value is0xFFFFFFFFand the core faults immediately with no output — which looks exactly like a failed flash. Please also confirm the .bin you are programming is the old non-partitioned build.4. If it still fails, please send me. (Grace@wiznet.io)
The exact error text from the tool, your Step 3 / Step 4 checkbox state, your baud rate and .bin size, and the return value of each command in the sequence above.
Separately — the "stops responding after a few downloads" problem
We can't diagnose this from here, but two things are worth checking:
CRC_HEADERis0x00001F00, andtransfer_sector()erases that sector at the start of every transfer. Please check your .map file and confirm yoursections.ldreally keeps0x1F00–0x1FFFfree — if anything else was placed there, every transfer erases live code or data, which would fit the symptom.Boot_Entry, note thatFLASH_IAP(IAP_PROG, dst, (uint8_t *)src, ...)passes a flash address as the source. All WIZnet IAP examples program from an SRAM buffer, so we'd recommend staging each sector through RAM instead.Also, in the
transfer_sector()you posted, thesectorargument is never copied intostaged_sector— we assume that was trimmed for the post, but worth a quick check.Best regards,
RE: RE: Unable to Flash W7500P, Write Protected
by kelanucr ·
Hi Grace, thanks for the reply!
The provided version of my code is the minimal example that I was running just before I was having flashing issues. I'm currently attempting to flash a version that uses the default ldscripts and contains no separate bootloader, it just goes directly to the main function.
I tried DUMP 00000000 00000010 to read the IVT as well as DUMP 10000000 00000100 to attempt to read the start of my image, before and after flashing, both return all 0s.
The ISP tool itself has multiple failure modes, sometimes it completes in ~1s with no error but it does not seem like anything was flashed as, when switched back to APP mode, there is no output on the simple UART port. If I select erase flash and data it runs ERAS MASS which returns 7. Occasionally, XMODEM will reach the NACK limit and abort.
I tried LOCK READ -> LOCK PROG -> ERAS CHIP -> LOCK READ -> REST -> LOCK READ (I also tried a manual power reset cycle instead of REST) just to see if any change to the lock info was sticking. The first LOCK READ returned C000000F FFFFFFFF, the second LOCK READ returned 00000000 00000000, the third LOCK READ then returned C000000F FFFFFFFF.
Unfortunately the board which was having this issue, now does not respond to the auto-baud sequence in ISP mode at all. The electrical connection between my serial bridge and the pins is good, I tested my serial bridge in loopback, so I think there are no more tests I can run and I have to throw in the towel at this point and proceed with swapping out the uC.
RE: RE: Unable to Flash W7500P, Write Protected
by Grace_Koo WIZnet ·
Hi,
A few notes before you swap the part:
Your lock test result is normal.
C000000F→ unlock →00000000→ reset →C000000Fis the expected behaviour. FLOCKR0/1 are volatile and reload to the locked state on every reset.The DUMP test was invalid — our omission. Erased flash reads back
FF, not00. All zeros is what you get when the Code Read Lock is still set, and it is set again after every reset.DUMPmust be issued in the same session as the unlock, with no reset in between:For the board that no longer answers
U: ISP mode runs entirely from the internal boot ROM and never touches flash, so firmware cannot cause this. Please measure at the package:Uresponse.One test left: SWD. In BOOT mode your application never runs, so
PA_03/PA_04are still SWCLK / SWDIO and a probe should see the core. If SWD enumerates, the chip is alive and the problem is in the ISP UART path; if not, it is the supply or the part.For the replacement board: in
jtag_sys_init()you reconfigurePA_03as a GPIO output for your bit-banged TCK.PA_03is SWCLK by default (PA_04is SWDIO), so once your application starts, SWD is gone and ISP becomes the only way back in. Moving TCK to another pin would leave you a recovery path independent of ISP.Best regards,
RE: Unable to Flash W7500P, Write Protected
by kelanucr ·
Hi Grace thanks for the update,
I ended up swapping the chip. However, before doing so my first attempt at unlocking the chip was to access it via SWD, the core never enumerated. I was using openocd with a TE0790. TEST, BOOT, RSTn were in the correct mode and I also measured the voltage rails on my scope and verified multiple times that the Simple UART connection was good.
Is this an issue that other people have had and in other cases what turned out to be the underlying cause?
RE: RE: Unable to Flash W7500P, Write Protected
by Grace_Koo WIZnet ·
Hi kelanucr
On your question: we do not have a documented case of a W7500P becoming unresponsive to both ISP and SWD, so I am checking internally whether this has been seen before and what the cause was. I will come back to you once I have an answer.
One thing I would like to confirm: is the board working normally with the replacement chip? If the same PCB is fine now, that points at the part; if the symptom returns after a while, it points at the board or the firmware. Your answer will decide where we look next.
Best regards,