NRF5240 External flash reads randomly failing at higher clock rates when bluetooth is running

[Shen2]

We are working with an NRF 52840 on a custom board.

We have an qspi AT25SF321B external flash chip, which is rated for a maximum frequency of 108 MHz.

We have noticed, that if we put the sck_frequency for the part above 8-10 MHz, then it works when bluetooth is not enabled, but when bluetooth is enabled, we are getting unflagged read failures, ie flash_read will return 0, but some of the bytes in the buffer will be incorrect.

The read failure rate is significant, We tested by writing 32 * 4k pages of data with the blue tooth off, confirming they read correctly, then turning on the bluetooth and reading the pages again and again on a loop.

Out of reading the 128k 10 times, 3 or 4 of those would contain read failures.

Our work around is to run the part with sck_frequency of 8 MHz, but it would be good to know what is causing the issue, especially as we have many peripherals working at the same time; blueooth, external flash, accelerometer, gps etc etc.

I've included the (hopefully) important parts of the dts below.

We can also see this issue on a 52840dk board with the external flash replaced with the AT25SF321B.

```

&qspi {

    status = "okay";

    pinctrl-0 = <&qspi_periphs_default>;

    pinctrl-1 = <&qspi_periphs_sleep>;

    pinctrl-names = "default", "sleep";

    at25sf321b: at25sf321b@0 {

        compatible = "nordic,qspi-nor";

        reg = <0>;

        size = <DT_SIZE_M(32)>;              // 32 mega bit total size

        jedec-id = [ 1F 87 01  ];

        sfdp-bfp = [

            e5 20 f1 ff  ff ff ff 01  44 eb 08 6b  08 3b 80 bb

            ee ff ff ff  ff ff 00 ff  ff ff 00 ff  0c 20 0f 52

            10 d8 00 ff  32 3a b1 00  84 e6 14 c2  00 01 00 80

            ff ff ff ff  f7 b3 d5 5c  00 06 61 ff  88 10 00 00

            00 00 00 00  00 00 00 00  00 00 00 00  ff ff ff ff  ];

       

        sck-frequency = <DT_FREQ_M(8)>;    // 108 MHz max freq, but 03h op code max feq = 55Mhz, and the actual clock seems to max out at ~30mhz

       

        has-dpd;                             // Deep power down = 0xB9 in datasheet

        t-enter-dpd = < 20000 >;

        t-exit-dpd = < 20000 >;

        partitions {

            compatible = "fixed-partitions";

            #address-cells = <1>;

            #size-cells = <1>;

            slot1_partition: partition@0 {

                label = "image-1";

                reg = <0x0000 0xe0000>;

            };

            external_partition: partition@e0000 {

                reg = <0xe0000 0x320000>;

            };

        };

    };

};
```

pin ctrl
```

    qspi_periphs_default: qspi_periphs_default {

        group1 {

            psels = <NRF_PSEL(QSPI_SCK, 1, 4)>,

                    <NRF_PSEL(QSPI_CSN, 1, 6)>,

                    <NRF_PSEL(QSPI_IO0, 1, 7)>,

                    <NRF_PSEL(QSPI_IO1, 1, 5)>,

                    <NRF_PSEL(QSPI_IO2, 1, 3)>,

                    <NRF_PSEL(QSPI_IO3, 1, 1)>;

        };

    };

    qspi_periphs_sleep: qspi_periphs_sleep {

        group1 {

            psels = <NRF_PSEL(QSPI_SCK, 1, 4)>,

                    <NRF_PSEL(QSPI_CSN, 1, 6)>,

                    <NRF_PSEL(QSPI_IO0, 1, 7)>,

                    <NRF_PSEL(QSPI_IO1, 1, 5)>,

                    <NRF_PSEL(QSPI_IO2, 1, 3)>,

                    <NRF_PSEL(QSPI_IO3, 1, 1)>;

            low-power-enable;

        };

    };
```

[Shen2]

The problem seems to be that the nrf52840 would work out the wait times based on 108mHz flash speed, but the clock would max out at 32 mHz, so the flash was being driven much slower than the wait was expecting. We ended up running the flash at 8mHz, where it works, but is slower than the potential flash or nrf52840 maximums