• State Verified Answer
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 130 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290325
Options

Unable to detect nRF9160 chip after flashing over JTAG via nRF9160-DK dev board

user116819

We have developed a prototype board based on the Thingy91 which contains both the nRF9160 and nRF52840 and many of the same connections. 

However, after a few successful attempts to flash both chips via the VS Code Nordic extension, the nRF9160 has become unresponsive.

Using this same setup of nRF9160-DK to our PCBA via the JTAG connector, we have successfully connected to the nRF52840 on the faulty board; both chips on the Thingy91 and both chips on another of our prototype boards. I have listed the devices found on the faulty board and working prototype below:

Correct Faulty

When attempting to connect to the "J-Link" device presented by the faulty board in the programmer we receive the following error message:
"Unsupported device. The detected device could not be recognized as neither JLink device nor Nordic USB device."

Additionally, when attempting to "Erase and Flash" the faulty board we receive the following error message:
Flashing build to undefined
west flash -d c:\nordic\apps\hello_world\build --skip-rebuild -r nrfjprog --dev-id 960033515 --erase

-- west flash: using runner nrfjprog
-- runners.nrfjprog: mass erase requested
-- runners.nrfjprog: Flashing file: C:\nordic\apps\hello_world\build\zephyr\merged.hex
ERROR: Unable to connect to a debugger.
ERROR: The --family option given with the command (or the default from
ERROR: nrfjprog.ini) does not match the device connected.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.
FATAL ERROR: command exited with status 18: nrfjprog --program 'C:\nordic\apps\hello_world\build\zephyr\merged.hex' --chiperase --verify -f NRF91 --snr 960033515
The terminal process terminated with exit code: 18.

Any help would be appreciated.

  • 0

    We have managed to rectify the issue by following the steps listed in the Updating firmware through external debug probe section of the guide up to the point where the nRF52 was uploaded with the UART bootloader HEX files for updating over USB and then attempting to talk to the nRF91 via USB. After finding the nRF9160 via USB we were then able to find it via JTAG.

    We have also been able to repeat the process which brought about this issue. It occurred by flashing both chips via the VS Code extension with firmware which contained nothing. This was in attempt to put both chips into low power mode by having nothing occurring on the threads. However, in reality the current draw increased to 10mA.

    If you would be able to supply us with example code that would put these chips into low power mode we would be most grateful, as all other forums relating to this topic only mention that by doing nothing the chips would default to low power mode, which in our situation was not the case.

  • +1

    Hello Ewan, 

    Ewan ALP said:
    If you would be able to supply us with example code that would put these chips into low power mode we would be most grateful, as all other forums relating to this topic only mention that by doing nothing the chips would default to low power mode, which in our situation was not the case.

    A requirement for the Thingy:91 to operate properly is that the nRF52840 is flashed with the Connectivity bridge application image. I assume that this applies to your custom board as well. For the nRF9160, the Hello World sample should be sufficient. 

    Regards. 

    Markus 

  • 0 in reply to user100109

    Hey Markus,

    Thank-you for getting back to me. Since uploading the bootloader image to the nrf52840 we are no longer running into issues with finding the nrf9160 SoC.

    However, with the 91 running the hello_world example script and the 52 running the bootloader image we are seeing an average current draw of 2.44mA, an order of magnitude higher than the uA of current we expected when using your chips in low power mode with all peripherals disconnected.

    Please could you advise why this current is much higher than expected and how to mitigate it?

  • 0

    Hello Ewan, 

    Ewan ALP said:
    Please could you advise why this current is much higher than expected and how to mitigate it?

    That is a little bit hard to say from distance, as there can be various reason. My first suspicion would be enabled peripherals. 

    You could start with adding spm.conf & mcuboot.conf to your Hello World sample, as demonstrated by the Serial LTE modem application. Adding the power saving options from each file should give you a reduced current consumption.

    Btw: I’m not sure if you still are able to comment my answer within this case, as status has been ‘‘Verified Answer’. In that case, please create a new ticket mentioning my name and referring to this case :-)

    Thanks & regards, 

    Markus

Related
Terms of service