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

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

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

[ace.johnny]

Excellent point about the compiler's merged .hex output. I was simply flashing single-core binaries, so J-Flash Lite met my modest needs at the time.

I don't think even the fully featured J-Flash version can program both nRF5340 cores at once, but honestly did not dive very deep into its settings after I had my nRF Connect environment set up.

Sorry to have derailed your search for assistance.

[puz_md]

No problem, thanks for your feedback anyway! I didn't know Nordic wanted to drop this feature. And J-Flash Lite indeed might be useful as an intermediate solution (at least it doesn't seem to lock the cores, like J-Link currently does after using the loadbin command).

[runsiv]

It was was not that we wanted to drop it, the issue was as you have experienced yourself the APPROTECT and the lack of option to recover the device during flashing. I can't unfortunately not think of any other easy way then either using nrfjprog or the programmer app. 

Regards

Runar