NRF52840 QSPI IFTIMING Problem

RE: NRF52840 QSPI IFTIMING Problem

haakonsh — Mon, 20 Dec 2021 11:58:43 GMT

I have seen some customers benefitting from using a 50 or 100ohms series resistor on the SPI lines in some designs, that can be an option, but I'm not certain it will work.

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Mon, 20 Dec 2021 11:11:38 GMT

This is the PCB diagram of our FLASH part connection, please refer to it.

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Mon, 20 Dec 2021 11:09:57 GMT

After changing the IFTIMING, some equipment is normal, but some machines are still abnormal. Because of time constraints and concerns about other effects, we can only be forced to adopt a 16MHZ method to solve this problem, but if there is a better way, we Want to improve.

RE: NRF52840 QSPI IFTIMING Problem

haakonsh — Mon, 20 Dec 2021 10:52:02 GMT

Then my recommendation is to either reduce the speed to 16MHz, or change the IFTIMINGs for all of your devices.

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Sat, 18 Dec 2021 03:06:38 GMT

Yes

RE: NRF52840 QSPI IFTIMING Problem

haakonsh — Fri, 17 Dec 2021 12:56:59 GMT

Have you enabled the High drive strength(H0H1) for the qspi gpio's ?

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Fri, 17 Dec 2021 05:49:21 GMT

Are there any new developments on this issue?

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Thu, 16 Dec 2021 03:42:17 GMT

I just discovered some interesting phenomena. When I reduce the power supply of the MCU from 3.3V to 3V, QSPI will become normal, and when I add a measurement line to the Clock pin, QSPI will also become Normally, this caused me to be unable to use the logic analyzer to view the timing. And when we heat NRF52840 with an air gun, this error phenomenon will also disappear.

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Thu, 16 Dec 2021 02:25:42 GMT

We tested a batch of machines after changing IFTIMING, and did not find any adverse effects on the use, or it may be that our testing time is relatively short. But this QSPI, we are directly connected to the MCU, there are no additional devices in between , But I did not use the pins recommended by NORDIC, we used the QSPI pins as follows:

//flash	
#define GPIO_FLASH_MOSI				GPIO1_10	//IO0
#define GPIO_FLASH_MISO				GPIO1_14	//IO1
#define GPIO_FLASH_SCLK				GPIO1_11
#define GPIO_FLASH_CS				GPIO1_15
	
#define GPIO_FLASH_WP				GPIO1_13	//IO2
#define GPIO_FLASH_HOLD				GPIO1_12	//IO3

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Thu, 16 Dec 2021 02:18:15 GMT

We tested a batch of "bad" devices and changed the IFTIMING register to 0x100. Most of the read and write data damage can be recovered, but some of them cannot be solved, but these can be solved by reducing the frequency to 16MHZ.

RE: NRF52840 QSPI IFTIMING Problem

haakonsh — Wed, 15 Dec 2021 10:12:55 GMT

In both cases (Bing and Youcan) it can be the result of ESD damage. A blown ESD fuse on one of the SPI pins will cause signal integrity issues.

But I think it's more likely an issue with the HW design, poor grounding will lead signal intergrity issues.

The device-to-device variation from our factory is insignificant. In order to make these variations significant there must be another factor like ESD issue during manufacturing or a spesific GND issue in the design.

RE: NRF52840 QSPI IFTIMING Problem

haakonsh — Wed, 15 Dec 2021 10:04:37 GMT

[quote user=""]We want to know why the problem products can fix this issue by change IFTIMING register while some most of the product (the other 96%) no need to change this register. And whether the IFTIMING register change would lead other unknown issues.[/quote]

I don't know why you see this issue exactly. I suggest we do a HW review to see if there is any obvious signal integrity issues in the design.
We don't know if changing the timings will lead to unknow problems in your design.

If you change the IFTIMING of the 'good' devices, does it have a negative impact, or do they continue to function as intended?

RE: NRF52840 QSPI IFTIMING Problem

you can123 — Wed, 15 Dec 2021 02:40:23 GMT

I also encountered this problem during production. The strange thing is that after I replaced the new 52840 chip, its read and write errors disappeared, but the wrong chip still continues to read and write errors. I haven't changed any registers, or it is normal if I change the frequency to 16MHZ? Is it due to the differences in the chip itself?