This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Unable to flash nRF9160 with "ninja flash"

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

  • 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

  • Hi,

     

    I can confirm that this is a bug in nrfjprog, where "--sectorerase" is failing in a certain corner case. The developers are actively looking into this, and we will push a new version as soon as its fixed and verified. Be on the lookout for a new version, but as a workaround until that is out; I'd recommend to use v9.8.1.

     

    Kind regards,

    Håkon

Related