nrfjprog qspi erase/read failing

[Ian]

Hello,

I'm trying to erase/read an external flash (MX25L6433F) connected to an nrf52840 using nrfjprog. I've created a .toml file for the configuration, see attached. The qspi pinout in the toml file is correct and I modified the custom instructions to write the correct data for quad operation.

I've played around with the read_mode, write_mode and frequency settings to no avail.

When I issue a --qspieraseall command, nrfjprog hangs at "Initializing the QSPI peripheral" until the 15 minute timeout is reached. See attached for a log file of this.

The --readqspi also hangs.

The nrf52840 is normally programmed with application firmware that uses the external flash as a littlefs filesystem. I can confirm that's working by reading out data using fs shell. The only difference is the application uses SPI not QSPI, but it is wired for QSPI.

nrfjprog version: 10.23.0 external
JLinkARM.dll version: 7.88j

nrf_qspi.zip

[Sigurd Hellesvik]

Hi,

Which version of the SDK do you use?

Try the JESD216 sample. Does that work?

Regards,
Sigurd Hellesvik

[Ian]

NCS 1.9.2

Although, when I'm trying to use nrfjprog, the device is erased. Shouldn't nrfjprog be able to read/erase the qspi regardless of the ncs sdk version?

This is a custom board, so I added a basic.dts for the it. I copied the qspi dts config from nrf52840dk_nrf52840.dts and only changed the pinout.

When running the sample, it prints "device not ready" in main.c. It looks like this is due to a timeout at the end of nrfx_qspi_init.

[Sigurd Hellesvik]

Ian said:

Shouldn't nrfjprog be able to read/erase the qspi regardless of the ncs sdk version?

Agreed. I just like to always ask.

Ian said:

When running the sample, it prints "device not ready" in main.c. It looks like this is due to a timeout at the end of nrfx_qspi_init.

It could look like you do not get a connection to the QSPI at all, then.

Connect an oscillosocpe or logic analyzer to the QSPI lines and see if you can see any communication here.

[Ian]

I looked into the QSPI lines using an oscilloscope and found that the CS line had a low slew rate and couldn't transition between hi/lo fast enough for QSPI, even at 2MHz. SPI worked because there were large delays around asserting/de-asserting the CS line. There must be some configuration for that.

The low slew rate appears to be caused by an internal RC circuit for reset pin 0.18 on the module I'm using (BT840XE).

I swapped the CS line to another free pin and QSPI works fine, with nrfjprog as well. Although, for nrfjprog to work, I need to program the sample first. nrfjprog doesn't allow me to read over qspi when the program is erased.

It's unfortunate that nrfjprog would indicate it was reading the external memory and fill a file with bad data when it was actually not reading anything. Or it would hang and require the process to be killed manually on Windows.