zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.78k stars 6.58k forks source link

flash_stm32_ospi: Command to enter 4-Byte Address Mode is missing, Winbond flash W25Q512 is not working correctly #76432

Closed arnebdr closed 2 weeks ago

arnebdr commented 3 months ago

Describe the bug QSPI Flash Winbond W25Q512 connected to STM32U5 is not working correctly. The Flash test fails and the bytes written are misaligned.

To Reproduce Steps to reproduce the behavior: Use a board with STM32 controller that has an octo spi port and connect the Flash in QSPI mode (Only CLK, CS, D0...D3 used of Octo SPI port).

  1. Compile the Flash Shell sample: west build -p always -b your_board samples/drivers/flash_shell
  2. Flash it to the Board: west flash
  3. In the shell find the correct flash device with "device list" command and execute the flash test: "flash test ospi-nor-flash@70000000 0x2000000 0x4000 1"
  4. Test Fails with "Verification ERROR!"

Expected behavior Flash Test passes, data written is identical to data read.

Impact Showstopper, Flash device not usable

Logs and console output Log Output:

Booting Zephyr OS build v3.7.0-228-g52672923e445 uart:~$ flash test ospi-nor-flash@70000000 0x2000000 0x4000 1 Erase OK. Write OK. Verification ERROR! Erase-Write-Verify test done.

uart:~$ flash erase ospi-nor-flash@70000000 0x0 0x1000 Erase success.

uart:~$ flash write ospi-nor-flash@70000000 0x0 0x00112233 0x44556677 Write OK. Verification ERROR!

uart:~$ flash read ospi-nor-flash@70000000 0x0 0x20 00000000: 88 88 88 33 22 11 00 77 66 55 44 ff ff ff ff ff |...3"..w fUD.....| 00000010: 88 88 88 33 22 11 00 77 66 55 44 ff ff ff ff ff |...3"..w fUD.....|

Environment (please complete the following information):

Solution I have traced this down to flash_stm32_ospi.c It uses 4 Byte Address mode for this flash (which is correct), but misses to send the "Enter 4-Byte Address Mode" Command to the Flash. By default this Flash chip starts in 3 Byte Address mode, which causes the data misalignment. With this patch the flash is working correctly, but I don't know if this is ok/required for all QSPI flash types: 0001-Patch-for-4-Byte-Address-activation-on-Winbond-Flash.patch

Log Output with patch above:

flash test ospi-nor-flash@70000000 0x2000000 0x4000 1 Erase OK. Write OK. Verified OK. Erase-Write-Verify test done.

FRASTM commented 3 months ago

@arnebdr your patch fixing the error for winbond NOR flash, should not affect other NOR flash. this has to be tested on stm32 disco boards with octo spi bus.

Note that The winbond NOR flash is W25Q512 is not octo but quad NOR spi flash. On the stm32U5 you probably have a configuration of the octospi peripheral in quad mode Screenshot from 2024-07-31 14-09-19

That configuration might require customization in the ospi driver : by default the octal-spi mode is selected and IO[0-7] are used for transfer.

  1. Probably the ocstopsi node should have spi-bus-width = <OSPI_QUAD_MODE>;
  2. it could also be a question of dummycycle adjustment for that mem device

The 4bytes address mode is already enabled on the stm32 qspi driver by qspi_program_addr_4b() function with a particular check on the JESD216, the bit0 of dw16.enter_4ba portion :

            /*
             * According to JESD216, the bit0 of dw16.enter_4ba
             * portion of flash description register 16 indicates
             * if it is enough to use 0xB7 instruction without
             * write enable to switch to 4 bytes addressing mode.
             * If bit 1 is set, a write enable is needed.
             */

I wonder if a similar test is relevant in the stm32 ospi driver, because with a simple stm32_ospi_enter_fourbyte_address_mode(), the samples/drivers/spi_flash fails on the b_u585i_iot02a (octospi config)

See https://github.com/FRASTM/zephyr/tree/stm32_ospi_4b

github-actions[bot] commented 4 weeks ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.