Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Fri, 25 Mar 2022 17:50:45 GMT

Thanks you very much. It will be very helpful when I need to use SPI in quad mode.

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Anthony Yuan — Fri, 25 Mar 2022 03:46:15 GMT

There is no need to write a complete new qspi_nor driver:

1, Add a new jesd216_dw15_qer_type, in my case JESD216_DW15_QER_S2B1V10.

2, Modify nrf_qspi_nor.c and use the jesd216_dw15_qer_type value to separate differences between DK's MX flash with GD flash, such as QE bit and BP4 bit and 2 more status registers and so on.

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Thu, 24 Mar 2022 18:18:05 GMT

Do you need to write your own driver ?? Just want to to know how much work is expected for my planning. Thanks

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Anthony Yuan — Thu, 24 Mar 2022 15:11:49 GMT

Thanks for your reply. I got GD25Q32E working using Quad mode.

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Tue, 22 Mar 2022 21:53:48 GMT

I use the SPI in Standard mode because I did not have time to fix the SPI driver in Quad mode. However, I may need to revisit this issue when my project requires faster access speed to the flash. Don't know if the latest Zephyr has the fix or have plan to support SPI Quad mode.

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Anthony Yuan — Thu, 10 Mar 2022 12:46:24 GMT

Hi,

I met a similar issue and raised a ticket: my ticket

Did you get your Gigadevice flash works?

Regards,

Anthony Yuan

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Simonr — Fri, 17 Sep 2021 09:03:05 GMT

Thank you for your input. I will forward your suggestions to our development team. Did you have any further questions, or can this case be closed?

Best regards,

Simon

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Thu, 16 Sep 2021 20:07:52 GMT

Hello Simon,

Thanks for the information for QSPI driver development. Will look into it.

However, the driver API generated in

/zephyr/include/generated/syscalls/flash.h

support the following functions

flash_erase(const struct device * dev, off_t offset, size_t size)

flash_read(const struct device * dev, off_t offset, void * data, size_t len)

flash_write(const struct device * dev, off_t offset, const void * data, size_t len)

flash_get_page_info_by_idx(const struct device * dev, uint32_t page_index, struct flash_pages_info * info)

It would be an improvement if we can change QSPI mode to be STANDARD, DUAL or QUAD with a function

flash_mode_set(const struct device * dev, ..... mode).

Just my 2 cents on the improvement of Zephyr

Thanks,

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Thu, 16 Sep 2021 13:27:46 GMT

Hello Simonr,

quad-enable-requirements = "S2B1";   <---  It not supported.  This should be an action
 item for Zephyr to support QE bit located in any bit position in the status register.

Only (['NONE', 'S2B1v1', 'S1B6', 'S2B7', 'S2B1v4', 'S2B1v5', 'S2B1v6']). are support now

As indicated in the following error message.

devicetree error: value of property 'quad-enable-requirements' on /soc/qspi@40029000/gd25lq80ceigr@0 in nrf52840dk_nrf52840.dts.pre.tmp ('S2B1') is not in 'enum' list in ........./zephyr/dts/bindings/mtd/nordic,qspi-nor.yaml (['NONE', 'S2B1v1', 'S1B6', 'S2B7', 'S2B1v4', 'S2B1v5', 'S2B1v6'])

quad-enable-requirements = "S1B6";   <---- It is the default setting for nRF52840DK, but
it hidden.  It need to be put in the BOARD.dts file explicitly, because many custom board using
nRF52840DK as the base for hw and sw reference and Nordic will get a lot of question like getting
88888... or 0000... in reading SPI flash if the quad-enable-requirements is not set correctly.

Just my 2cents for future improvement on quad-enable-requirements

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Simonr — Fri, 10 Sep 2021 13:16:00 GMT

No, we don't have any example projects using QSPI in NCS as of yet I'm afraid. You will have to implement the QSPI driver in an example (like the spi_flash example) yourself to make it able to operate in quad mode. You will need to add the following drivers:

ncs\modules\hal\nordic\nrfx\hal\nrf_qspi.h
ncs\modules\hal\nordic\nrfx\drivers\src\nrfx_qspi.c
ncs\modules\hal\nordic\nrfx\drivers\include\nrfx_qspi.h

Best regards,

Simon

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Fri, 10 Sep 2021 01:33:00 GMT

Hello Simonr,

Thanks for the effort to help me.

Trying quad-enable-requirements = "NONE";

or

quad-enable-requirements = "S2B1";   /* for bit 9 */

I am able to read and write to the external QSPI flash GD25LQ80C, but only in standard mode

I am checking the Quad mode configuration of the QSPI interface the nRF52840.

Not sure if the example in/ncs/zephyr/samples/drivers/spi_flash can operate in quad mode.

static inline int flash_write(const struct device * dev, off_t offset, const void * data, size_t len).

build\zephyr\include\generated\syscalls\flash.h. sending out 0x02(Page Program) instead of 0x32(Quad Page Program), so it is operating in standard mode because 0x02 is command for standard mode.

Is there any example in Nordic SDK using QSPI in Zephyr RTOS environment ??

Is the SPI driver API generated support Quad mode ??

Thanks again for the solution using

quad-enable-requirements

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Simonr — Thu, 09 Sep 2021 06:03:22 GMT

QE bit handling is specified by the quad-enable-requirements property of the nordic, qspi-nor binding. The default value of this property is "S1B6", and hence the driver sets bit 6 of the first status register byte to enable the Quad mode (that's what is required for the MX25R64). Apart from the "S1B6" value, the QSPI NOR Flash driver also supports the "NONE" value, which prevents the driver from setting any bit in the status register to enable the Quad mode. It seems that for both GD25LQ80C and W25Q32FV this setting should be used, as the QE bit is non-volatile in both flash chips. Thus, the QE bit should be set once to 1 and the driver should be prevented from writing the status register, hence the following line should be added in the "nordic, qspi-nor" compatible mode:

quad-enable-requirements = "NONE";

For reference, there is a commit that introduced the current way of handling the QE bit (previously, the QSPI NOR Flash driver used a Kconfig option for specifying this bit). The commit message explains why this is done how it is.

Best regards,

Simon

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Simonr — Wed, 08 Sep 2021 08:55:46 GMT

Thanks for the added information. I'll keep you posted on the status of this issue.

Best regards,

Simon

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Tue, 07 Sep 2021 17:46:26 GMT

Thanks for your help in following up with this issue.

I checked other flash chips from Winbond and Cyress. It will have similar problem. Bit 6 is sector protect and bit 9 is QE

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

Simonr — Mon, 06 Sep 2021 11:47:16 GMT

Sorry about the late reply but I've been out of office the last few days. This has now been reported to our developers and we're looking into it. Thank you very much for the thorough post.

Best regards,

Simon

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Thu, 02 Sep 2021 19:34:14 GMT

Bit 6 is BP4 block protect bit GD25LQ80C

Bit 6 is QE bit for MX25R64 flash chip

RE: Look like a hard coded bug in API generated in build\zephyr\include\generated\syscalls\flash.h

jchan12345 — Thu, 02 Sep 2021 18:25:05 GMT

I inserted comments in the picture captured from the logic analyzer to help engineers to understand this problem.

The software I used is based on

/ncs/zephyr/samples/drivers/spi_flash

You will need to use a custom board or change the external flash chip on the nRF52840DK in order to see the failure.

This problem may be related to some of the cases reading 0x88 0x88, ...... or 0x00 0x00, ... when using zephryncs/zephyr/samples/drivers/spi_flash