nRF5340 and nRF9160 general questions

[Franco Fourie]

Good day,

I would like to confirm the following points regarding the nRF9160 and nRF5340:

nRF9160 

1. The modem firmware binary is programmed through the SWD and not a UART port?

2. The Application core is also programmed using the SWD interface?

3. Does it ship from the factory with a bootloader? 

nRF5340

1. The application core and network processor are programmed through the SWD interface and can be simultaneously debugged by creating two debug sessions? 

2. The network core only supports a single UART instance, while the application core can support up to 4 UART instances?

3. What interface is used to load the bootloader (SWD and/or UART) and also are there specific GPIO pins that need to be used if the bootloader is uploaded using UART.

4. Does it ship from the factory with a bootloader? 

[Charlie]

Hi Franco,

nRF9160 

1. The modem firmware binary is programmed through the SWD and not a UART port?

2. The Application core is also programmed using the SWD interface?

At the development stage, you need to use the SWD interface for programming and debugging with a debugger like J-Link.

3. Does it ship from the factory with a bootloader? 

A bootloader is used when you need to update FW for either modem firmware or application firmware for your existing product. For secure concerns, you should set up and program your own secure bootloader for your product, so only your company can update them.

nRF5340

1. The application core and network processor are programmed through the SWD interface and can be simultaneously debugged by creating two debug sessions? 

Yes,  you get debug logs from different UART outputs.

2. The network core only supports a single UART instance, while the application core can support up to 4 UART instances?

Yes

3. What interface is used to load the bootloader (SWD and/or UART) and also are there specific GPIO pins that need to be used if the bootloader is uploaded using UART.

It should be programmed with SWD so your application firmware can be updated with bootloader through UART, BLE, WiFi, Cellular network, and so on. NCS/ZEPHYR use MCUboot as bootloader Using MCUboot in nRF Connect SDK — MCUboot 1.8.99 documentation (nordicsemi.com)

4. Does it ship from the factory with a bootloader? 

Please refer to the answer to nRF9160 3).

I list related documents as below, you will get more familiar with nRF9160 and nRF5340 development after reading them.

Working with nRF91 Series — nRF Connect SDK 1.9.0 documentation (nordicsemi.com)

Working with nRF53 Series — nRF Connect SDK 1.9.0 documentation (nordicsemi.com)

nRF5340 samples — nRF Connect SDK 1.9.0 documentation (nordicsemi.com)

nRF9160 samples — nRF Connect SDK 1.9.0 documentation (nordicsemi.com)

Applications — nRF Connect SDK 1.9.0 documentation (nordicsemi.com)

https://infocenter.nordicsemi.com/topic/struct_nrf53/struct/nrf5340.html

Best regards,

Charlie

[Franco Fourie]

Hi Charlie thank you for the information.

Just one more additional question with regards to the single UART on the network core:

Can any GPIO pins be used for this UART as long as it is not being used by another peripheral?

I could not find any info on this in the documentation and assume that this is the case?

BR

Franco

[Charlie]

nRF5340 (nordicsemi.com)

Section 7.38.9 Registers

Best regards,

Charlie

[Franco Fourie]

Hi Charlie,

Just one more question on this. 

Can the modem firmware be uploaded also using the SWD interface during both the development and production phase, or should UART be used for production programming?

[Charlie]

1)SWD can be used on both.

2)Application Firmware update through UART needs you to program a bootloader through SWD first.

3)The two methods can exit at the same time.

Best regards,

Charlie

[Frikkie Badenhorst]

Hi Charlie,

I am a colleague of Franco, and have some more questions on this post.

Charlie said:

A bootloader is used when you need to update FW for either modem firmware or application firmware for your existing product. For secure concerns, you should set up and program your own secure bootloader for your product, so only your company can update them.

What exactly is meant by for secure concerns? Is MCUBoot only capable of booting into non-secure regions?

To give some context, we have already started development on a product which will contain the nrf5340 and nrf9160 on the same board (nrf9160 does not have enough memory so we need an external app processor). We will for now only be running example code on the nrf9160. Development have started on the nrf5340 however, and we decided to use IAR as compiler without Zephyr. The network core is for now forced off. The nrf5340 application core has to be upgradeable however. For now we do not care if the app runs in secure or non-secure memory. Will we be able to use MCUBoot for this purposes?

I also have some questions regarding Trustzone and the secure/non-secure regions. We are using the IAR startup files obtainable from the Nordic SDK here https://www.nordicsemi.com/Products/Development-tools/nRF-MDK. The very first instruction that is executed, 

SAU->CTRL |= (1 << SAU_CTRL_ALLNS_Pos);

to our understanding sets the entire chip to non-secure. Is this indeed the case? If this is the case, surely our application is also running from "non-secure" flash. We are however not able to access any non-secure peripherals, only peripherals that are secure. This is quite confusing?

If we are running from non-secure regions, surely we should not be able to access secure peripherals and similarly, if we are running from secure regions, we should still be able to access non-secure peripherals?

Any insight would be greatly appreciated. 

Kind regards,

Frikkie

[Charlie]

Hi Frikkie,

Your questions are quite messy, I am not sure where to get started to answer your questions. I will just list them according to my understanding and give you some advice:

1) Development Environment

Frikkie Badenhorst said:

nrf9160 does not have enough memory so we need an external app processor

Sounds like you should choose an external flash instead of another processer.

Frikkie Badenhorst said:

we decided to use IAR as compiler without Zephyr.

Is there any special reason you do not use nRF Connect SDK(based on Zephyr)? I have never met a customer who does not use the official nRF Connect SDK for their development. You would hardly get support if you use a rarely used development solution. All the documents I referred to by far are all targeted to NCS documents.

2) MCUboot

Frikkie Badenhorst said:

What exactly is meant by for secure concerns?

The secure concerns mean if you use the default key to sign your image, other developers can easily replace your application firmware with their firmware and do whatever they want with your device.

Frikkie Badenhorst said:

Is MCUBoot only capable of booting into non-secure regions?

Not sure if I understand you, for nRF5340, MCU starts from the secure domain, so mcuboot as a bootloader has to be in the secure domain.

3)  secure and non-secure domains

Frikkie Badenhorst said:

our understanding sets the entire chip to non-secure. Is this indeed the case?

You need bootloader+ SPM(configure peripherals used in the non-secure domain) in the secure domain and running your application on the secure domain.

Features of nRF91 Series — nRF Connect SDK 1.9.1 documentation (nordicsemi.com)

Using a custom Secure Partition Manager with your application - Software - nRF Connect SDK guides - Nordic DevZone (nordicsemi.com)

Secure Partition Manager — nRF Connect SDK 1.9.1 documentation (nordicsemi.com)

 

Please turn back to nRF Connect SDK, and try to read and learn the document.

Best regards,

Charlie

[Frikkie Badenhorst]

Hi,

Most questions are answered and looks like we will be able to use MCUBoot. Some more remarks/questions:

1)

Charlie said:

ounds like you should choose an external flash instead of another processer.

We need both processors as we will also be using the 2.4GHz radio and NFC on the nrf5340

2)

Charlie said:

Is there any special reason you do not use nRF Connect SDK(based on Zephyr)?

Yes. We already have our application running on multiple other devices using a different OS (not thread based). From our investigations the SDK forces you to use Zephyr, hence our entire application will have to be redesigned. We also found the tools (and Zephyr) not to be very user friendly and quite cumbersome. From previous discussions with Nordic, we understand that modem and radio libraries are OS-independant, so we should be able to use it still. IAR is also miles ahead of GCC as a compiler, and unfortunately it seems as if the SDK is GCC only.

3) At startup, we are trying to access non-secure peripherals, for example NRF_UARTE0_NS. We however get an exception when trying to access it (we can only access NRF_UARTE0_S).

Charlie said:

MCU starts from the secure domain

Should we not be able to access non-secure peripherals when running in the secure domain?

[Charlie]

Hi Frikkie,

1)2) Understood.

3) Since you do not use NCS, so you cannot use the secure and non-secure domains management solutions like SPM or TFM.

Frikkie Badenhorst said:

At startup, we are trying to access non-secure peripherals, for example NRF_UARTE0_NS. We however get an exception when trying to access it (we can only access NRF_UARTE0_S).

This should not be an issue, as nRF9160 PS section 6.15.4 mentions:

Secure code can access both secure peripherals and non-secure peripherals.

Hard to say where the issue might happen since you are using your own solution. Maybe referring to the steps from the SPM source code could give you some hints.

Best regards,

Charlie

[Franco Fourie]

Hi Charlie. Me again. 

I would like some clarification regarding the Coexistence interface of the nRF9160.

"COEX0 – Input to the LTE modem from the external device. When active high, indicates that the
external device transceiver is turned on. When internal GPS is used, COEX0 can be used as active-high
control for the external LNA component."

I feel this is a bit ambiguous since it seems like COEX0 is used as output from the LTE modem when the internal GPS is used, however, this is never explicitly stated.

Additionally, I would assume that this pin needs to be reconfigured as an output when the internal GPS is used. Does this happen automatically internal, or is additional configuration required?

Kind regards.

Franco

[Charlie]

Hi Franco,

Please just create a new ticket for this topic.

You will get help from our nRF9160 HW expert.

Best regards,

Charlie