nRF9160 modem firmware upgrade firmware loader not starting

[ruimtepuin]

Hi,

I'm making my own program to upgrade the nRF9160's modem firmware over SWD. So far, application note nAN41 has helped a lot, but I'm getting stuck when trying to get the firmware loader up and running. After the loader has been programmed into RAM and the IPC transaction is started, the IPC.MODEM_CTRL_EVENT doesn't get set within 10 seconds. The modem control event does get asserted without faults when reading the key digest, so the modem has booted correctly I also verified whether the contents of the loader matched the written RAM, which is the case.

To check whether I'm missing something, I compared the programming sequence of the nrf_dfu_api with nAN41. I saw some differences but it didn't seem to help:

• All IPC events are acknowledged after the IPC is configured (self.acknowlage_events()).
• The RAM is powered on prior to making all sections non-secure (self.api.power_ram_all()). Not sure if it's needed and what this function does as it's a proprietary driver.
• The modem response is read after acknowledging events (self.read_be(0x2000000C))

Is there some step I'm maybe missing after loading the firmware loader? It's not stated in the manual, but do I need to enable the core again because it's halted? If it is, how do I set the correct starting address in the MCU where it should boot from?

Thanks,
Martin

[ovrebekk]

Hi 

To start with a stupid question, any reason why you couldn't just use one of the provided scripts to do this, rather than make your own?

Best regards
Torbjørn

[ruimtepuin]

Hi Torbjørn,

I could've expected this question would come ;)

Currently the modem firmware can only be updated with PCs, because the nrfjprog libs are only compiled for x86. Having to use a PC rather than something like a Raspberry PI for production programming is way overkill.

Nordic also only provides exclusive support for programming with J-link devices, which is expensive (because you're actually not allowed to use the DK for programming external targets).

If I make something myself I also have much more flexibility and can update firmware in parallel on multiple devices easier, shortening the process.

Regards,
Martin

[ovrebekk]

Hi Martin

ruimtepuin said:

Currently the modem firmware can only be updated with PCs, because the nrfjprog libs are only compiled for x86.

Version 10.14.0 of the nRF Command Line tools for Linux64 should also support ARM targets. Below is an excerpt from the release notes:

• Installers:

  - Update bundled Segger installers and tar balls to v7.52d

  - Provide universal binaries for MacOS M1 and x86_64.

  - Provide binaries for armhf raspbian targets.

ruimtepuin said:

Nordic also only provides exclusive support for programming with J-link devices, which is expensive (because you're actually not allowed to use the DK for programming external targets).

This is true. The license for the Segger chip on the DK's doesn't cover production programming, but I would argue that paying 350 Euros for a J-Link Base programmer is not very expensive. The DK's are not designed to be used in a production setting, and any time you have to spend debugging why a kit stops working, or on implementing your own programming solutions, carries a cost as well (as they say, time is money). 

ruimtepuin said:

If I make something myself I also have much more flexibility and can update firmware in parallel on multiple devices easier, shortening the process.

We will do our best to support you if you go down this route, but be aware that it is likely to require a significant investment in development time, compared to using the tools that we already provide. 

Best regards
Torbjørn 

[ruimtepuin]

Hi Torbjørn,

ovrebekk said:

Version 10.14.0 of the nRF Command Line tools for Linux64 should also support ARM targets.

That was just released when I created the ticket apparently ;), but awesome that it's finally supported!

Anyway I still want to try to update the modem firmware parallel on multiple devices, without having to use multiple J-links.

Because it would be hard to debug the issue without me having much information on what happens when it fails, I decided to compare what the J-link does with nAN41. With a logic analyser I was able to extract the different steps the J-link takes and saw quite some differences

1. First, the J-link writes and reads some debug registers (DHCSR, DEMCR, DSCSR, ...).
2. After reading the modem keys as usual (step 4.2.3), it will load some other firmware loader. Starting with 0x5049656D and ending with 0xBED856EB.
3. Then it starts the IPC, until the transfer has completed, after which it starts again with allocating RAM (step 4.1.4) and loading, this time the real, firmware loader.

Especially the extra firmware loader seems weird to me, since there is no mention of it in nAN41. However, loading this firmware loader myself did not help, because the modem didn't respond to this event either.

However, when I first uploaded the modem firmware with the J-link, my program suddenly worked! So the J-link is configuring the nRF9160 in some way that it does accept the loader. The change the J-link made is persistent, so I can power cycle the nRF9160 and it still accepts my firmware loader. I also didn't get anymore issues afterwards.

Do you maybe have an idea on what perquisites are required to start the modem firmware upgrade process? It seems that it's some configuration in flash, since the configuration is persistent and the modem keeps acknowledging the loader after power cycles.

Regards,
Martin

[ovrebekk]

Hi Martin

I discussed this with one of the developers, but he was not aware of any persistent prerequisites that needed to be in place in order to update the modem. 

Could you please let me know which version of the nRF9160DK you are using?

Also, it could be interesting to check the state of the UICR registers between the working and non working state, in case there could be some UICR configuration that is missing. 

To check this could you please read out the UICR registers through nrfjprog, both when the board is working and when it is not?

nrfjprog --readuicr uicr.hex

Best regards
Torbjørn