Using USB mass storage device to flash nRF5340-DK does not work

[puz_md]

Hello,

when I plug in my nRF5340-DK, a mass storage device called "JLINK" appears on my Windows PC.

Normally, it is possible to copy .hex files with firmware to the mass storage device, and it is flashed automatically via the integrated SEGGER JLink debugger of the development kit. I used this method successfully in the past with the nRF52832 development kit.

For the nRF5340-DK, this method seems not to work anymore. I cannot flash merged_domains.hex via the mass storage device. If I try, a FAIL.TXT file appears, that doesn't provide much useful info. What went wrong?

I tried flashing a Bluetooth project with a small Peripheral implementation:

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="My Bluetooth"
CONFIG_BT_HCI=y

After some testing, I found out that I can flash build\zephyr\merged.hex and *\zephyr.hex (I didn't verify the data, but I didn't get the FAIL.TXT file with these).

Then, I tried the .hex files from the hci_rpmsg subproject: build\hci_rpmsg\zephyr\merged_CPUNET.hex, *\app.hex and *\zephyr.hex, neither of them can be flashed.

Could it be that only the application core can be flashed this way? And the network core cannot even be flashed separately (without flash data from both core's address spaces being merged into one file)?

It would be nice if you could solve this issue. As we want to provide a Nordic development kit to one of our suppliers so that he can implement a mobile app based on our characteristics / Bluetooth profile, but without receiving one of our Bluetooth devices (which are not yet finished). So, we need a convenient way to provide firmware updates to our supplier, which would ideally be just a drag & drop of firmware files to the USB drive, like before with the nRF52832.

By the way, I have a lot of touble working with the flashing tools Nordic Semiconductor provides for the nRF5340. The cores always lock up at unexpected times, and it is impossible updating only part of the Flash memory with leaving other partitions untouched. Unless the nRF Connect for VS Code plugin is used for flashing, which is no option for our supplier. Using the nRF Programmer or some command line based flashing tool always seems to overwrite the partitons I want to keep, and/or locking the MCU... so, using the USB mass storage device would be the most convenient way to provide firmware updates to our supplier...

Best regards,
Michael

[runsiv]

Hi Michael just a few questions to get started. 

1. Which version of the 5350dk are you using? I know there has been an issue for DKs with a nRF5340 as debugger(if the PCA number covers a SoC then we can presume its an older debugger and i expect drag and drop to work) 

2. Which version of command line tools are you using?

I expect some of the issue you have seen is related to app protect. My recommendation would be to use nrjfprog to flash the application or to use the nRF Connect for Desktop Programmer app. 

Regards

Runar

[puz_md]

Hi runsiv,

I'm using PCA10095, version 2.0.1 from 2022.36.

Command line tools are 10.23.2 (downloaded/installed on November 2024).

When is app protect normally activated on the MCU? Why does it activate automatically even when I don't want it to protect the core? Is there any way to disable app protect reliably?

Like I mentioned before, the cores get locked automatically all the time, without me wanting them to get locked. I also have this issue on our self-produced nRF5340-based PCB's when accessing them with a SEGGER J-Link, newest software/driver version.

Best regards,
Michael

[ace.johnny]

I had a similar problem trying to flash an nRF5340 Audio DK using the J-Link Mass Storage Device enumeration, and was told by Elfving in this thread that support for that feature has been removed.

I instead used SEGGER's J-Flash Lite application to program the board, which admittedly required a few more clicks, but was still pretty end-user simple compared to a command line incantation.

Hope this helps.

[runsiv]

puz_md said:

Command line tools are 10.23.2 (downloaded/installed on November 2024).

I would recommend upgrading to the latest version

puz_md said:

When is app protect normally activated on the MCU? Why does it activate automatically even when I don't want it to protect the core? Is there any way to disable app protect reliably?

You can read more about APPROTECT here. Its enabled by default as a security feature, however it is possible to deactivate it on your application.  APPROTECT will protect against gaining access to the SoC resources, which may include sensitive information. To reprogram the device with APPROTECT enabled, the debugger first needs to erase the non-volatile memory using the Control Access Port (CTRL-AP) interface before being able to regain access, which ensures that any sensitive data gets wiped out before debug port access is restored

You can see here how to enable/disable approtect, you can also see Susheels reply here https://devzone.nordicsemi.com/f/nordic-q-a/100570/access-port-protection-nrf52840-rev3-vs-rev2?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending 

Regards

Runar

[puz_md]

It would really be sad if this feature was lost. It was the most convenient way to flash the eval boards, as long as you want to flash the whole device. It was also much faster than VS Code (taking 30 seconds to program a nRF5340 now, which is way too long).

I guess the main problem is that the nRF5340 is a dual core MCU, and JLink usually connects only to one of them. So, the core would have to be selected based on the memory offsets that are to be flashed.

J-Flash Lite (newest version) also doesn't work for me, it is also unable to program merged flash data to both cores (you have to select the desired core at startup). Maybe it might work if I find a way to split up merged_domains.hex into the different cores.