[nRF52840dk] nrfjprog always reading external flash least significant bit as 0

[Brad Campbell]

I'm trying to use nrfjprog to read and write the mx25r6435f external flash on the nRF52840dk board (I have version 3.0.0). However, what I am noticing is that nrfjprog always reads the least significant bit of every byte as 0. For example:

$ nrfjprog --erasepage 0x12000000-0x12000004
WARNING: An address for the --erasepage operation is not aligned to the start
WARNING: of page.
Initializing the QSPI peripheral.
Erasing range [0x00000000 - 0x00000FFF] in the external memory device.
Uninitializing the QSPI peripheral.

and then immediately after:

nrfjprog --memrd 0x12000000 --log
[ #####                ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x00
[                      ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x00
[ #################### ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - Done
0x12000000: EEEEEEEE

The read always returns with each byte having a 0 as the least significant bit. This also happens when I try to program the external flash. The erase works successfully, the write works successfully, but the verify (read) "fails" because nrfjprog thinks the LSB is 0.

I've run code on the nrf that reads the flash and it reads correctly (after erase it is all 0xff and after programming with nrfjprog I get the expected values.

My programming:

cat a.bin
hello from tock flash

arm-none-eabi-objcopy -v -I binary -O ihex --change-addresses 0x12000000  a.bin a.hex
nrfjprog --qspichiperase --program a.hex

Is this a known issue? What can I do?

Debugging

I've tried every version of nrfjprog back to 10.12.1. Through 10.13 I see the same issue. At 10.12.1 it seems I can no longer read the flash, probably because I have a newer version of the nRF52840-dk.

My Setup

I'm on MacOS Ventura (13.3.1a).

[Brad Campbell]

Ok, I've found a way to get the QSPI read to work as expected (dk 3.0.0):

$ nrfjprog --memrd 0x12000000 --log
0x12000000: EEEEEEEE                              |....|
$ nrfjprog --eraseuicr
Erasing UICR flash area.
Applying system reset.
$ nrfjprog --memrd 0x12000000 --log
0x12000000: FFFFFFFF                              |....|

When I look at the UICR:

❯ nrfjprog --version
nrfjprog version: 10.17.3 external
JLinkARM.dll version: 7.80c
❯ nrfjprog --memrd 0x12000000 --log
0x12000000: EEEEEEEE                              |....|
❯ nrfjprog --readuicr uicr.bin
Storing data in 'uicr.bin'.
❯ hexdump -C uicr.bin
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000200  21 00 00 00 21 00 00 00  5a 00 00 00 ff ff ff ff  |!...!...Z.......|
00000210  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001000





❯ nrfjprog --eraseuicr
Erasing UICR flash area.
Applying system reset.
❯ nrfjprog --memrd 0x12000000 --log
0x12000000: FFFFFFFF                              |....|
❯ nrfjprog --readuicr uicr_erased.bin
Storing data in 'uicr_erased.bin'.
❯ hexdump -C uicr_erased.bin
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000200  ff ff ff ff ff ff ff ff  5a 00 00 00 ff ff ff ff  |........Z.......|
00000210  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00001000

Why does setting the reset pin affect the QSPI connection? For this test I changed the reset pin to a random GPIO and it still doesn't work. For all previous tests the reset pin has been the standard P0.18. So it doesn't seem to be which reset pin, just if one is set.

This also raises the question of how this issue isn't affecting more users (no one using the QSPI? something else happening?).