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

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

Einar Thorsrud — Mon, 05 Jun 2023 14:39:59 GMT

Hi,

nrfjprog is as little intrusive as possible, so there is normally no reset when trying to read/write QSPI flash, so the SPIM0 peripheral is not reset in this case, which seems to cause problems as it was configured to use one if the QSPI pins. So you need to somehow ensure that SPIM0 does not use the pin. That could be by reconfiguring your firmware, erasing the firmware or something else. Or you could simply perform a reset.

The following script python script using pynrfjprog demonstrate how to to reset the device halt it an read QSPI memory. I did not get a chance to test with a device that has the pin configured with SPM0 today, but hopefully it would work (for a device that does not it dumps the first 0x100 bytes from QSPI memory successfully):

from pynrfjprog import LowLevel

segger_serial_number = 683741650
with LowLevel.API('NRF52') as api:
    api.connect_to_emu_with_snr(segger_serial_number)
    api.sys_reset()
    api.halt()
    api.qspi_configure()
    api.qspi_init()
    data = api.qspi_read(0, 0x100) # Reading
    print(data)

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

Brad Campbell — Fri, 02 Jun 2023 17:29:55 GMT

Ok, I've tracked this down. I'm using the same QSPI lines as normal SPI to read and write the mx25r6435f flash chip from the nrf52840 itself. It seems like somehow configuring the MOSI pin (P0.21 on the nRF52840) with the spim0 peripheral causes that pin to be held low, resulting in the LSB of each nibble reading 0. When I remove the code that setups the SPI interface to read the external flash in our software, reading the flash through nrfjprog works as expected.

How should I make these two use cases co-exist? Is the correct approach to make sure the SPIM0 peripheral is disabled when not in active use, because when it is enabled it seems to hold MOSI low?

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

Brad Campbell — Fri, 02 Jun 2023 16:18:41 GMT

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

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

Brad Campbell — Fri, 02 Jun 2023 13:52:46 GMT

I'm trying to see if any other variables correlate. Here are the jlink firmware versions flashed on my two nrf52840dks:

nrf52840dk 3.0.0 (2022.36) [qspi flash read fails]

J-Link>h
J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Nov  7 2022 16:22:01
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 00m 05s
S/N: 1050271823
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V
Target connection not established yet but required for command.
Device "NRF52" selected.

nrf52840dk 1.1.0 (2019.12) [qspi flash read works]

J-Link>h
J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Nov  7 2022 16:22:01
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 00m 05s
S/N: 1050271823
USB speed mode: Full speed (12 MBit/s)
VTref=3.300V
Target connection not established yet but required for command.
Device "NRF52" selected.

Obviously they are different because of the different hardware, but they have the same compilation date. I'm not sure if this could even have any effect.

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

Brad Campbell — Fri, 02 Jun 2023 13:38:36 GMT

I had a colleague try:

nRF52840dk 2.0.1 (2020.13)
Ubuntu 22.04

$ nrfjprog --memrd 0x12000000 --log
0x12000000: EEEEEEEE                              |....|
$ nrfjprog --version
nrfjprog version: 10.8.0 
JLinkARM.dll version: 6.44

Different nrfjprog versions but same result.

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

Brad Campbell — Fri, 02 Jun 2023 13:28:03 GMT

I just tried with a different nrf52840dk 3.0.0 (2022.36) on Mac:

$ 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 --version
nrfjprog version: 10.17.3 external
JLinkARM.dll version: 7.80c
$ nrfjprog --memrd 0x12000000 --log
0x12000000: EEEEEEEE                              |....|

Same behavior.

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

Einar Thorsrud — Fri, 02 Jun 2023 13:20:47 GMT

Hi,

That is interesting. However, I have not been able to reproduce on a nrf52840 DK version 3.0.0 either. Can you try downgrading Segger J-Link to 7.80c which is the version we curently support with the lates nRF Command Line tools?

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

Brad Campbell — Thu, 01 Jun 2023 19:01:22 GMT

I tried on windows with three nrf52840dks:

C:\Windows\System32>nrfjprog --version
nrfjprog version: 10.18.1 external
JLinkARM.dll version: 7.82a

1.1.0 (2019.12):

C:\Windows\System32>nrfjprog --memrd 0x12000000
[ #####                ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[                      ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[ #################### ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - Done

0x12000000: FFFFFFFF                              |....|

2.0.1 (2020.14):

C:\Windows\System32>nrfjprog --memrd 0x12000000
[ #####                ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[                      ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[ #################### ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - Done

0x12000000: FFFFFFFF                              |....|

3.0.0 (2022.36):

C:\Windows\System32>nrfjprog --memrd 0x12000000
[ #####                ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[                      ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - 0x0000 of 0x0004       
[ #################### ]   0.000s | Reading external memory, 0x0004 bytes @ 0x00000000 - Done

0x12000000: EEEEEEEE                              |....|

That points to something about the change to the 3.0.0 revision of the nrf52840dk.

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

Brad Campbell — Thu, 01 Jun 2023 16:55:06 GMT

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.

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

Einar Thorsrud — Thu, 01 Jun 2023 13:18:52 GMT

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.

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

Brad Campbell — Wed, 31 May 2023 20:11:08 GMT

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.

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

Einar Thorsrud — Wed, 31 May 2023 08:24:35 GMT

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?

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

Brad Campbell — Fri, 26 May 2023 17:30:18 GMT

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.