nrfjprog --readqspi unreliable

[Torsten Robitzki]

Hello,

I have a custom hardware, with an external 128MB QSPI flash memory connected to a nRF5340. My current task at hand, is to store firmware update images for MCUBoot there. The firmware is stored by the application using a custom driver for the external flash memory.

I've used nrfjprog already, to read measurement data from that external flash memory and that worked quite well. That's why it toke me quite some time to realize, that nrfjprog is doing something stupid here.

The external flash memory has a page size of 4kB and when reading the flash memory content, every first byte of every empty page reads 0x0f instead of 0xff. I changed the operations to be used to a single data line (read_mode = "FASTREAD"; write_mode = "PP") and slowed down the QSPI clock frequency to M2. Attaching a logic analyser, shows, that the flash memory response with 0xff (not 0x0f) to page read request.

Before opening this request, I updated the Segger JLink software to the newest version and then, the next try to read the flash content, showed the correct results! I did an other test and used `

west build --pristine -b"nrf5340dk/nrf5340/cpuapp" --build-dir ./build --sysbuild  .` && `west flash --recover ` to install new firmware on the nRF53. A following read, using nrfjprog showed again, wrong results (0x0f at the begin of every page), while the logic analyser still shows the correct picture.

I power reset, both custom hardware and debugger (J-Trace Pro) but that didn't fixed the issue. Combined with my observation from this ticket (https://devzone.nordicsemi.com/f/nordic-q-a/115570/using-mcuboot-with-nrf5340), that sometimes build errors are not reproducible, my suspicion is, that the `west build` or `west flash` command is changing some configuration data outside of the build folder.

I've used ´nrfjprog` a few month ago and could not find any issues. What changed to the project, was an update to nRF Connect SDK v2.7.99-cs2.

nrfjprog version: 10.24.2 external

JLinkARM.dll version: 8.10d

Here, a screen shot of the QSPI trace:

% nrfjprog --readqspi recording.bin --qspiini ./config.toml 
[ #################### ]   0.000s | Reading external memory, 0x200000 bytes @ 0x00000000 - Done                        
Storing data in 'recording.bin'.
% hexdump -C recording.bin | head                           
00000000  0f ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Attached is the entire trace and the used configuration file.

Best regards

Torsten

[Edvin]

Hello,

According to the nRF5340's QSPI documentation, only the dedicated QSPI pins should be used for QSPI:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/qspi.html#ariaid-title2

So it could be that what you are seeing is a result of this. 

Is it too late to change the GPIOs?

Best regards,

Edvin

[Torsten Robitzki]

Hi Edvin,

thanks for the fast response. No problem, the pins are correctly allocated (see picture in the next post). The custom driver also works and also, nrfjprog has already worked correctly with that hardware. I guess, nrfjprog is ignoring the QSPI pin configuration in the config.toml file (I received that file as an example from a colleague of yours) .

I've corrected the pin configuration in the config.toml file and the behavior stays the same. When I add a mistake into that file, I receive an error, so I'm sure, that the configuration is not totally ignored. I can also see my configured [qspi.custom.instructions] in the logic analyzer trace (which switches the flash memory to use 32 bit addressing).

best regards

Torsten

[Torsten Robitzki]

[Edvin]

Ok, I understand. 

Yes, it also states that the configs will not be used in the comment above the QSPI pins. 

So when changing to normal (non-quad) SPI, and you analyze the pins, and you see the 0xFF using saleae, do you still read 0x0F through the nRF53? Or does the readout change when you are doing these changes?

What I find a bit strange is the amount of clock ticks before the MISO line goes high:

And it is a bit difficult to understand whether the first 0xFF is actually referring to the first byte on the page or not. 

Is it possible to write something to the first flash page:

0x01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 ...

Something like that, and then you can read it back, to check whether the SPI starts at 01, or if it starts somewhere later?

Best regards,

Edvin

[Torsten Robitzki]

Hi Edvin,

Originally, I used read_mode = "READ4O", write_mode = "PP4IO" and frequency = "M16" in the toml file. That resulted (read by nrfjprog) in reading 0x88, 0x88 as the very first two bytes of every page begin of an empty flash memory.

I changed that settings to the one, that are now in the toml file and nrfjprog started to report these 0x0f bytes at the beginning of every page of an empty flash memory page, while on the logic analyzer trace, clearly 0xff is visible.

The late start of the MISO line going high, is because, the command on the MOSI line is quite large (0x0b plus 4 times 0x00, as the 32 bit address, plus 8 dummy bits; see 7.25.10 of the nrf5340 data sheet).

I wrote a small test program, that erased the first page, and wrote that patter to the beginning of the page:

static constexpr std::uint8_t pattern[] = {
    0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
    0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
    0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77,
    0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff
};

Reading that back from the flash memory, using nrfjprog, yields this pattern:

00000000  00 10 20 30 40 50 60 70  80 90 a0 b0 c0 d0 e0 f1  |.. 0@P`p........|
00000010  00 01 12 23 34 45 56 67  78 89 9a ab bc cd de ef  |...#4EVgx.......|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*

The traces look like I would expect them (attached in the next messages).

I think, the most notable data point with this issue is, that it worked _once_ after I've installed the newest version of the JLink software (see above).

best regards

Torsten

[Torsten Robitzki]

Trace is not accepted as being too large. Let me know, if you are interested into the trace, then I would provide you a download link.