Good day!

I got very unusual flash error, so want to ask techsupport. I have a number (30+) of CH579M-based boards, all of which have exactly same behavior: 256 bytes of flash at addresses 0x00008400..0x000084FF are non-writable, i.e. contain a 0xFF value. All other flash bytes are writable-erasable as expected, but that half-page is not. I am surprised, if not more. Have that area any special meaning, aliasing, lock bits or so? What can be the reason for that?

CH579 erase needs to be as per 512B size. Note: You need to erase before writing and then reading. If the write fails, you can provide the following printing information to check whether the return value of the write function is successful.

Hi!

I am not a new with CH579. Of cause, erasing is done with 512 bytes pages. The code (bootloader), already got a lot of testing over the time. Moreover, it was used on the same IC to flash previous firmware versions. From the code structure, the flash page in question is not somewhere special. Nothing like endless updates, partial write and so on. It just the one flash page in the middle of the main firmware, which was wrote no more than 10 times. But, at some point, it failed to update.

The flash page 0x00008400...0x000085FF (i.e. 512 bytes) was erased, but after that it's first half (0x00008400..0x000084FF) became non-writable (stuck at 0xFFFFFFFF state). Second half of that page (0x00008500..0x000085FF) is perfectly writable.

It can be just a funny case, but I already got more than 30 ICs with exactly same behaviour. End devices passed tests, got firmware and used to work nicely at customer site, until firmware update was issued.

As a temporary workaround, I did a special firmware build, where the page 0x00008400..0x000085FF was excluded by linker script settings and filled with 0xFFFFFFFF. That trick solves issue, firmware works well. But the root reason for flash damage still unclear.

Hello, this question is convenient to send to the mailbox lpc@wch.cn. If it is convenient, provide the print information that is erased, that is, the print that is erased for the 0xFF, and the corresponding data after the write, and we find the problem according to the print information.