Hello. I am playing with a nucleo_u575zi_q and noticed that the flash driver did not matched the reference manual when writing. While the manual specifies that only quad-words (128 bits, see Sec. 7.3.7 "Flash main memory programming sequences") can be used, the driver uses double-words (64 bits). The write-block-size is also set to 16 in the device tree, but this parameters is hardcoded to 8 at a couple of places in the driver. I wrote a small test program (see below) to settle who was right and the manual seems correct.
I did a quick workaround (see https://github.com/zephyrproject-rtos/zephyr/commit/7bcb8ebf38d9612511b173bf509e486645ac7e80) and the test program worked as expected. However the L5 seems to be using a width of 64 bits when writing, so a better solution would be needed. Maybe it would be nice to take the write-block-size from the device tree to remove some of the hardcoded constants?
I can propose a better fix if I get some feedback on the desired way to fix this issue.
Result with master: writing blocks of 8 bytes is allowed, but the readback is either 0xff or wrong. Writing 16 bytes at a time failed in the 1st bank but worked in the 2nd bank (by luck?). Output (edited for brevity):
Describe the bug
Hello. I am playing with a nucleo_u575zi_q and noticed that the flash driver did not matched the reference manual when writing. While the manual specifies that only quad-words (128 bits, see Sec. 7.3.7 "Flash main memory programming sequences") can be used, the driver uses double-words (64 bits). The
write-block-size
is also set to 16 in the device tree, but this parameters is hardcoded to 8 at a couple of places in the driver. I wrote a small test program (see below) to settle who was right and the manual seems correct.I did a quick workaround (see https://github.com/zephyrproject-rtos/zephyr/commit/7bcb8ebf38d9612511b173bf509e486645ac7e80) and the test program worked as expected. However the L5 seems to be using a width of 64 bits when writing, so a better solution would be needed. Maybe it would be nice to take the
write-block-size
from the device tree to remove some of the hardcoded constants?I can propose a better fix if I get some feedback on the desired way to fix this issue.
To Reproduce
See the test program here: https://github.com/zephyrproject-rtos/zephyr/commit/4821b3c65c29956aa3230d1c81bdf1c5c13e4045. It is writing 8-byte and 16-byte blocks of random data in reverse order and reads back to compare. Both flash banks are tested.
Result with master: writing blocks of 8 bytes is allowed, but the readback is either 0xff or wrong. Writing 16 bytes at a time failed in the 1st bank but worked in the 2nd bank (by luck?). Output (edited for brevity):
Result with my workaround: writing blocks of 8 bytes returns an error. Writing 16 bytes at a time works in both banks. Output: