Unable to flash nRF9160 with "ninja flash"

[phipi]

I'm building some of the samples using command line in Ubuntu and have a strange issue. Everything builds fine, the merged.hex file is generated, however when I try to flash the device using "ninja flash" the boot loader never runs the application:

SPM: MSP_NS 20023088
SPM: prepare to jump to Non-Secure image

However the following all work:

1. Flashing the image using J-FlashLite

2. nrfjprog -e; nrfjprof --program merged.hex

3. nrfjprog -e; ninja flash

SPM: MSP_NS 200236c8
SPM: prepare to jump to Non-Secure image
***** Booting Zephyr OS 1.14.99 *****
The AT host sample started

Does anyone know what the issue might be here? Is ninja flash corrupting something during the erase?

For some reason I am currently unable to reply to the below posts so I'm adding this here:

$ nrfjprog -v
nrfjprog version: 10.1.1
JLinkARM.dll version: 6.46g

[Håkon Alseth]

Hi,

 

Q1: What project are you compiling? Is this the behavior for all projects?

Q2: What revision/tag have you checked out? 

Does anyone know what the issue might be here? Is ninja flash corrupting something during the erase?

ninja just acts as the build system. In the background, nrfjprog is being called, so it should be equal to manually flashing.

 

Kind regards,

Håkon

[phipi]

I get the same result with nrf/samples/nrf9160/at_client, and with mqtt_simple. I haven't tried any more at this time.

This is on v0.4.0

How would I find out exactly which nrfjprog commands are being executed by ninja? There must be some sort of discrepancy if #3 above works.

[MJD093]

If I'm reading your problem right, you are finding that invoking ninja flash is not actually flashing a different application to the DK right?

I have had a few instances of ninja flash just straight up not doing anything but reseting the device with the same firmware that was on it previously.

I generally just invoke a JLinkExe erase by writing to the NVMC Erase All register:

w4 0x50039504 2 //sets NVMC config register to erase enabled
w4 0x5003950c 1 //NVMC eraseall

That should invoke an erase of the nRF9160, then ninja flash it again and it should actually work this time. I believe this is what nrfjprog does under the hood for nRF9160s, my version of JLink doesn't identify the cortex as an nRF9160, only as M33. So some manual tinkering is used. Alternatively you could try the Desktop NRF Connect Programmer application but I don't know if that is avaliable on Linux.

I use this method to erase and reflash a DK remotely.

Edit: Actually re-reading your OP, I guess this isn't your issue but for #2, you haven't set an nRF family type so it probably won't manipulate the NVMC which you must do to enable flashing and erasing. You could try it this way as I described to erase, then do it again and set NVMC to write enabled, then use 'loadfile <merged.hex>' to flash the firmware. See page 32 of the OPS on NVMC config.

[Håkon Alseth]

What is the output of nrfjprog -v? Is either JLink (should be v6.40 or newer) or nrfjprog old (v9.8.1 or newer)?

If you have an old one in path, it might not accept "-f nrf91" (west invokes nrfjprog with this switch), but still try to program it. West checks the connected jlinks, provides a list if more than one is present, then passes that on to nrfjprog with --ids switch.

You can find the latest nrfjprog here: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools/Download#infotabs

  

Cheers,

Håkon

[phipi]

Looks like my tools are all up to date:

$ nrfjprog -v
nrfjprog version: 10.1.1
JLinkARM.dll version: 6.46g

[Håkon Alseth]

Hi,

 

I'm running ubuntu 19.04.

I have a slightly older JLinkARM installation, but it seems to work as intended here:

$ nrfjprog -v
nrfjprog version: 10.1.1
JLinkARM.dll version: 6.46a

  

By adding verbose flag to ninja (ninja -v flash), you can see the inputs to the west command, and by adding -v to west again, I get this output:

$ cd /opt/ncs/nrf/samples/nrf9160/at_client/build && /usr/bin/cmake -E env /home/hkn/.local/bin/west -v flash --skip-rebuild
ZEPHYR_BASE=/opt/ncs/zephyr (origin: env)
Using runner: nrfjprog
nrfjprog --ids
Flashing file: /opt/ncs/nrf/samples/nrf9160/at_client/build/zephyr/merged.hex
nrfjprog --program /opt/ncs/nrf/samples/nrf9160/at_client/build/zephyr/merged.hex -f NRF91 --snr 960044273 --sectorerase
Parsing hex file.
Erasing page at address 0x0.
Erasing page at address 0x1000.
Erasing page at address 0x2000.
Erasing page at address 0x3000.
Erasing page at address 0x4000.
Erasing page at address 0x5000.
Erasing page at address 0x6000.
Erasing page at address 0x7000.
Erasing page at address 0xC000.
Erasing page at address 0xD000.
Erasing page at address 0xE000.
Erasing page at address 0xF000.
Erasing page at address 0x10000.
Erasing page at address 0x11000.
Erasing page at address 0x12000.
Erasing page at address 0x13000.
Erasing page at address 0x14000.
Erasing page at address 0x15000.
Erasing page at address 0x16000.
Erasing page at address 0x17000.
Erasing page at address 0x18000.
Erasing page at address 0x19000.
Erasing page at address 0x1A000.
Erasing page at address 0x1B000.
Erasing page at address 0x1C000.
Erasing page at address 0x1D000.
Erasing page at address 0x1E000.
Erasing page at address 0x1F000.
Erasing page at address 0x20000.
Erasing page at address 0x21000.
Erasing page at address 0x22000.
Erasing page at address 0x23000.
Erasing page at address 0x24000.
Erasing page at address 0x25000.
Erasing page at address 0x26000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
nrfjprog --pinreset -f NRF91 --snr 960044273
Applying pin reset.
Board with serial number 960044273 flashed successfully.

 

Compared to how you do it, west does a --sectorerase instead of a full erase (nrfjprog -e).

You could try the same procedure and see if that works? remember to do a --reset afterwards to start up the device again.

 

*edit*: I think you're right. There seems to be something with the sectorerase functionality in this release, especially on linux. I'll dig some more and update you.

 

Kind regards,

Håkon