• State Verified Answer
  • Replies 5 replies
  • Subscribers 70 subscribers
  • Views 65 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339370
Options

nrf9160 on custom board crashes when nrf_modem_lib_init is called

mackz

I have a custom board with a nrf9160 on it that has been working for the last three months but last week when i was evaluating low power modes on the board i couldn't talk to the 9160 chip.

I would just get:

nrfjprog -r
[error] [ Client] - Encountered error -102: Command connect_to_emu_with_snr executed for 181 milliseconds with result -102
ERROR: Unable to connect to a debugger.
[error] [ Worker] - An unknown error.
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.
NOTE: For additional output, try running again with logging enabled (--log).
NOTE: Any generated log error messages will be displayed.

And the board would draw around 30mA.

I have been trying to find out what is causing it and discovered that if i run nrfjprog -e right at power up i can talk to the chip and flash new firmware on it.

This made it possible to find that the device works if i never initialise the modem. If i call nrf_modem_lib_init() i loose the communication with the device and i have to power it off and run nrfjprog -e again to be able to communicate with the chip.

I am using nrf connect sdk 2.6.1 on Ubuntu 22.04.5 but have tried building and flashing on 20.04 aswell. The chip has SICA B1 2205CU written on it.

I have tried to get a modem trace from the device but i get 0 bytes written after i've lost the device.

I have run nrfjprog --recover and tried to flash the modem with version 1.3.5, 1.3.6 and 1.3.7 firmware but it makes no difference, when i try to init the modem i loose all communication with the chip and the device draws around 30 mA.

Because it is not possible to init the modem it is not possible to send any at commands to do a factoryreset.

What could be causing this?

  • 0

    Hi,

     

    I have a custom board with a nrf9160 on it that has been working for the last three months but last week when i was evaluating low power modes on the board i couldn't talk to the 9160 chip.

    How many of your boards behave like this?

     

    The most common issue when the modem does not boot up is that one or more of the RESERVED pins (pins 104-127) are shorted somehow:

    https://docs.nordicsemi.com/bundle/ps_nrf9160/page/pin.html

     

    This will cause problems when trying to communicate with the modem. Have you tried to clean/resolder the specific device?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    It seems weird to get a short after several months of running fine. The board has just been laying on my desk. I have one other board that i have experienced kind of the same issue with, but on that one i can't get any communication working. I think that i might have flashed the chip with a firmware that i had not tested so it might have been left resetting with hardfaults. But i can't really understand why that would make the modem behave the way it is.

  • 0 in reply to mackz

    Hi,

     

    There is no changes done to the hardware at all, ie. no changes in the external circuitry (caps or similar)? Could this be due to mechanical stress on the board itself? Have you tried to rework (warm it up) to see if it starts working as expected again?

    I have run nrfjprog --recover and tried to flash the modem with version 1.3.5, 1.3.6 and 1.3.7 firmware but it makes no difference, when i try to init the modem i loose all communication with the chip and the device draws around 30 mA.

    Are you able to flash the modem at all?

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth

    Yeah i was able to change the modem firmware after running nrfjprog -e, i have now switched to a new chip and the board is working but i am still not really sure what went wrong.

  • +1 in reply to mackz

    Hi,

     

    Glad to hear that the new chip is working as intended. What can have happened with the former would be guessing from my side, but ESD/EOS, or possibly mechanical stress, are potential causes.

    If you see this with more devices, please be sure to contact us again and we can put you in contact with our QA department.

     

    Kind regards,

    Håkon

Related