To adapt the flash driver for WCH's CH32VXX series MCUs, it is necessary to modify the definition of the variable 'uint8_t erase_value' in the existing flash driver.

[Colt-Ma]

Is your feature request related to a problem? Please describe.

For most MCUs, the flash memory is 0xFF after erasure. In the flash driver, the content type defined for erased flash is:

struct flash_parameters {
    const size_t write_block_size;
    uint8_t erase_value; /* Byte value of erased flash */
};

The erase_value variable is defined as 8-bit, but for WCH's CH32Vxx series, the flash content after erasure is 16-bit aligned 0xE339. This causes all code in the storage subsystem that relies on this variable to be unsuitable for this series of MCUs, which reduces the usefulness of the Zephyr operating system for applications on these MCUs.

Describe the solution you'd like

Change the definition of the variable 'uint8_t erase_value' and related code to accommodate more flash devices

Describe alternatives you've considered

No response

[nordicjm]

This doesn't really make sense, flash fundamentally works by being "erased" which is a high-power operation that resets all parts of a sector back to 1, it then sets bits in that sector to 0 on a write, you cannot set them back to 1, that is not how flash operates, the only way to do that is by erasing the whole sector, so I would say if you get 0xe339 erase value then your flash chip or flash driver are very broken because you would fundamentally be unable to ever store 0xffff in the sectors

[Colt-Ma]

I know all that you said, but the CH32VXX series MCUs are truly a special case. I asked the original manufacturer's technical support engineer, and their answer was exactly this: after erasure, not all bit positions are set to 1. This is mentioned in their user manual.

…

--------------原始邮件-------------- 发件人："Jamie ***@***.***&gt;; 发送时间：2025年12月4日(星期四) 下午4:34 收件人："zephyrproject-rtos/zephyr" ***@***.***&gt;; 抄送："Colt-Ma ***@***.***&gt;;"Author ***@***.***&gt;; 主题：Re: [zephyrproject-rtos/zephyr] To adapt the flash driver for WCH's CH32VXX series MCUs, it is necessary to modify the definition of the variable 'uint8_t erase_value' in the existing flash driver. (Issue #100490) ----------------------------------- nordicjm北欧 left a comment 发表评论(zephyrproject-rtos/zephyr#100490)（zephyrproject-rtos/zephyry#100490） This doesn't really make sense, flash fundamentally works by being "erased" which is a high-power operation that resets 这确实讲不通，闪存的运作原理实际上是通过“擦除”来实现，而这是一种高功率操作，能够进行重置all全部 parts of a sector back to 1, it then sets bits in that sector to 0 on a write, you cannot set them back to 1, that is not how flash operates, the only way to do that is by erasing the whole sector, so I would say if you get 0xe339 erase value then your flash chip or flash driver are very broken某个扇区的一部分被还原至&nbsp;1&nbsp;的状态，随后写入操作会将该扇区内的位设置为&nbsp;0。然而，你无法再将这些位重新设置为&nbsp;1，因为闪存的工作原理并非如此。要实现这一目标，唯一的方法是彻底擦除整个扇区。因此，我认为如果得到的擦除值为&nbsp;0xe339，那么你的闪存芯片或闪存驱动程序很可能已经严重受损 —&amp;mdash; Reply to this email directly, 请直接回复此邮件view it on GitHub在&nbsp;GitHub&nbsp;上查看它, or 或unsubscribe退订. You are receiving this because you authored the thread.你收到此信息是因为你创建了该主题帖。Message ID: 消息标识:<zephyrproject-rtos/zephyr/issues/100490/3610877050<zephyrproject-rtos/zephyr/issues/100490/3610877050@@githubGitHub.com&gt;com&gt;

[nordicjm]

If not all bit positions are set to 0xff and you can only "set" bits from a 1 to 0 then the whole flash design of that chip is broken and no amount of having a default value will work because you can't write data to it e.g. if your data is 0xee 0xf1 0xba 0x99 then the resultant data in flash will be completely different. Unless this is just that the flash value really is 0xff 0xff but their design is completely broken and they can't be bothered to fix it.

Anyhow, this would be a huge change because it is expected that the flash erase value in many places, many libraries, many applications is a single byte, and sorry to say but I don't see the value in having to rework many different things to add support just for one manufacturer's broken design, and impact everyone else's devices with an increased footprint

[Colt-Ma]

<img width="666" height="619" alt="Image" src="https://github.com/user-attachments/assets/aa6d0f1a-84e1-438a-b446-c632e0fc9fc2" /> This is the description of flash erasure from the original manufacturer's user manual. I have written my own program to confirm that this is indeed the case, and I have also consulted their engineers. This series of MCUs works this way, so if you want to use the flash of this MCU, you need to modify the existing code.

…

--------------原始邮件-------------- 发件人："Jamie ***@***.***&gt;; 发送时间：2025年12月4日(星期四) 晚上6:26 收件人："zephyrproject-rtos/zephyr" ***@***.***&gt;; 抄送："Colt-Ma ***@***.***&gt;;"Author ***@***.***&gt;; 主题：Re: [zephyrproject-rtos/zephyr] To adapt the flash driver for WCH's CH32VXX series MCUs, it is necessary to modify the definition of the variable 'uint8_t erase_value' in the existing flash driver. (Issue #100490) ----------------------------------- nordicjm left a comment (zephyrproject-rtos/zephyr#100490) If not all bit positions are set to 0xff and you can only "set" bits from a 1 to 0 then the whole flash design of that chip is broken and no amount of having a default value will work because you can't write data to it e.g. if your data is 0xee 0xf1 0xba 0x99 then the resultant data in flash will be completely different — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;