• State Verified Answer
  • Replies 13 replies
  • Subscribers 86 subscribers
  • Views 3749 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 308591
Options

[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).

  • 0

    Including the example of programming specific data:

    $ nrfjprog --qspisectorerase --program a.hex --verify
[ #################### ]   0.144s | Erase file - Done erasing
[ #################### ]   0.217s | Program file - Done programming
[error] [  nRF52] - Failed while performing Verify operation on target address 301989910. one
-160: Data does not match in address range [0x12000000 - 0x12000015] (XIP)
Expected byte value 0x65 but read 0x64 at address 0x12000001.
[error] [  nRF52] - Failed while verifying device. -160: Data does not match in address range [0x12000000 - 0x12000015] (XIP)
Expected byte value 0x65 but read 0x64 at address 0x12000001.
[error] [ Worker] - Data does not match in address range [0x12000000 - 0x12000015] (XIP)
Expected byte value 0x65 but read 0x64 at address 0x12000001.
[error] [ Client] - Encountered error -160: Command verify_file executed for 179 milliseconds with result -160
ERROR: Write verify failed.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

    The contents of the file:

    $ hexdump -C a.bin
00000000  68 65 6c 6c 6f 20 66 72  6f 6d 20 74 6f 63 6b 20  |hello from tock |
00000010  66 6c 61 73 68 0a                                 |flash.|
00000016

    Trying to read flash after the program using nrfjprog:

    $ nrfjprog --readqspi f.bin
...
$ hexdump -C f.bin
00000000  68 64 6c 6c 6e 20 66 62  6e 6c 20 64 6e 62 6a 20  |hdlln fbnl dnbj |
00000010  66 6c 60 62 68 0a ee ee  ee ee ee ee ee ee ee ee  |fl`bh...........|
00000020  ee ee ee ee ee ee ee ee  ee ee ee ee ee ee ee ee  |................|
*
00800000

    And reading some of flash from the actual nRF52840:

    Finished read! 30
0x68
0x65
0x6c
0x6c
0x6f
0x20
0x66
0x72
0x6f
0x6d
0x20
0x74
0x6f
0x63
0x6b
0x20
0x66
0x6c
0x61
0x73
0x68
0x0a
0xee
0xee
0xff
0xff
0xff
0xff
0xff
0xff

    So the actual contents of the flash are correct, it's nrfjprog that is reading them incorrectly.

  • 0

    Hi,

    I have never seen anything like this before. I see you have tested with some old nrfjprog versions, which is the newest version you have tested? The latest version depend on the host, but if for instance using Linux (64 bit), the latest is 10.21.0.

    Also, do you have another nRF52840 DK that you can test to see if you see the same on that one?

  • 0 in reply to Einar Thorsrud

    I've tried every version on Mac from 10.13.0 to 10.21.0 with the same result. I've tried with two different 3.0.0 dk boards.

    I asked a colleague to try, with Ubuntu 22.04, an older nrf52840dk, and nrjprog 10.8.0, with the same result.

    Another colleague on Ubuntu 20.04, older dk, and nrfjprog 10.12.1, had it work as expected.

  • 0 in reply to Brad Campbell

    Hi,

    That is interesting. I have been  testing on Ubuntu and it works as expected on my end (with nrfjprog 10.17.3 as there are QSPI memory related issues with newer nrfjprog releases). I will test on macOS as well and get back to you.

  • 0

    I found an older nRF52840dk to try on mac.

    $ nrfjprog --version
nrfjprog version: 10.17.3 external
JLinkARM.dll version: 7.86h

    nRF52840dk v1.1.0 (2019.12):

    $ nrfjprog --qspieraseall
WARNING: An operation that can take up to several minutes is being executed.
WARNING: Please remain patient.
Initializing the QSPI peripheral.
Erasing.
Uninitializing the QSPI peripheral.
$ nrfjprog --memrd 0x12000000 --log
0x12000000: FFFFFFFF                              |....|

    nRF52840dk v3.0.0 (2022.36):

    $ nrfjprog --qspieraseall
WARNING: An operation that can take up to several minutes is being executed.
WARNING: Please remain patient.
Initializing the QSPI peripheral.
Erasing.
Uninitializing the QSPI peripheral.
$ nrfjprog --memrd 0x12000000 --log
0x12000000: EEEEEEEE                              |....|

    So, on my machine at least, even with nrfjprog 10.17.3, there is something different about the newer nRF52840dk in how it reads the external flash.

Related
Terms of service