nRF5340 and nRF9160 general questions

RE: nRF5340 and nRF9160 general questions

Charlie — Wed, 23 Mar 2022 12:11:01 GMT

Hi Franco,

Please just create a new ticket for this topic.

You will get help from our nRF9160 HW expert.

Best regards,

Charlie

RE: nRF5340 and nRF9160 general questions

Franco Fourie — Wed, 23 Mar 2022 11:14:40 GMT

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

RE: nRF5340 and nRF9160 general questions

Charlie — Tue, 22 Mar 2022 13:21:38 GMT

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.

[quote user="Frikkie Badenhorst"]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).[/quote]

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

RE: nRF5340 and nRF9160 general questions

Frikkie Badenhorst — Tue, 22 Mar 2022 10:19:24 GMT

Hi,

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

[quote userid="93921" url="~/f/nordic-q-a/85087/nrf5340-and-nrf9160-general-questions/359188#359188"]ounds like you should choose an external flash instead of another processer.[/quote]

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

[quote userid="93921" url="~/f/nordic-q-a/85087/nrf5340-and-nrf9160-general-questions/359188#359188"]Is there any special reason you do not use nRF Connect SDK(based on Zephyr)?[/quote]

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).

[quote userid="93921" url="~/f/nordic-q-a/85087/nrf5340-and-nrf9160-general-questions/359188#359188"]MCU starts from the secure domain[/quote]

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

RE: nRF5340 and nRF9160 general questions

Charlie — Mon, 21 Mar 2022 15:05:35 GMT

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

[quote user="Frikkie Badenhorst"]nrf9160 does not have enough memory so we need an external app processor[/quote]

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

[quote user="Frikkie Badenhorst"]we decided to use IAR as compiler without Zephyr. [/quote]

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

[quote user="Frikkie Badenhorst"]What exactly is meant by for secure concerns?[/quote]

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.

[quote user="Frikkie Badenhorst"]Is MCUBoot only capable of booting into non-secure regions?[/quote]

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

[quote user="Frikkie Badenhorst"]our understanding sets the entire chip to non-secure. Is this indeed the case?[/quote]

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

RE: nRF5340 and nRF9160 general questions

Frikkie Badenhorst — Fri, 18 Mar 2022 14:53:57 GMT

Hi Charlie,

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

[quote userid="93921" url="~/f/nordic-q-a/85087/nrf5340-and-nrf9160-general-questions/354800#354800"]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.[/quote]

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

RE: nRF5340 and nRF9160 general questions

Charlie — Tue, 15 Mar 2022 17:13:01 GMT

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

RE: nRF5340 and nRF9160 general questions

Franco Fourie — Tue, 15 Mar 2022 14:02:23 GMT

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?

RE: nRF5340 and nRF9160 general questions

Charlie — Fri, 25 Feb 2022 09:14:44 GMT

nRF5340 (nordicsemi.com)

Section 7.38.9 Registers

Best regards,

Charlie

RE: nRF5340 and nRF9160 general questions

Franco Fourie — Fri, 25 Feb 2022 09:08:48 GMT

Could you please link this document?

BR

Franco

RE: nRF5340 and nRF9160 general questions

Charlie — Fri, 25 Feb 2022 09:04:00 GMT

The general document cover UART used by network core.

See Table 2. Instances

Best regards,

Charlie

RE: nRF5340 and nRF9160 general questions

Franco Fourie — Fri, 25 Feb 2022 08:43:53 GMT

Hi Charlie,

Thanks, yes I saw this, hence my assumption.

I couldn't find any documentation where they made mention of the configuration of the UART on the network core.

Thanks

RE: nRF5340 and nRF9160 general questions

Charlie — Fri, 25 Feb 2022 08:17:55 GMT

Hi Franco,

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

nRF53 Series > nRF5340 > nRF5340 Product Specification > Peripherals > UARTE mentions:

The GPIOs used for each UART interface can be chosen from any GPIO on the device and are independently configurable. This enables device pinout flexibility and efficient use of board space and signal routing.

Best regards,

Charlie

RE: nRF5340 and nRF9160 general questions

Franco Fourie — Thu, 24 Feb 2022 21:30:31 GMT

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

RE: nRF5340 and nRF9160 general questions

Charlie — Thu, 24 Feb 2022 12:02:28 GMT

Hi Franco,

nRF9160

[quote user=""]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?[/quote]

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

[quote user=""]
3. Does it ship from the factory with a bootloader? [/quote]

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

[quote user=""]

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

[/quote]

Yes, you get debug logs from different UART outputs.

[quote user=""]2. The network core only supports a single UART instance, while the application core can support up to 4 UART instances?[/quote]

Yes

[quote user=""]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.[/quote]

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)

[quote user=""]
4. Does it ship from the factory with a bootloader? [/quote]

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