Custom nrf54L15 based board running on Zephyr OS advices

[Fernando Fontes]

Hi everyone,

I’m starting a new project using the nRF54L15 MCU. I’ve worked with the nRF52840 and nRF52832 before, but this is my first time with the nRF54 series.

Due to time constraints, I decided to skip the dev kit and go straight to designing a custom board that includes everything I need. The main capabilities of my board are:

• Multi-Interface Communication: RS485 for industrial networks, 4G cellular connectivity, and a display interface

• Precision Control: Multiple PWM outputs for motors, plus dedicated GPIOs for valves and actuators

• Sensor Integration: 5-channel ADC for pressure and level sensors, along with digital inputs for temperature and overcurrent monitoring

• User Interface: 4-button navigation system for the GUI

I’m still waiting for the first five prototypes, but I already have a Zephyr OS project compiling with the correct device tree setup for my custom board.

What I’m currently struggling with is the dual-core architecture:

• I’ve created the devicetree for the main Cortex-M33 (cpuapp), but I’m unsure how to approach the cpuflpr (Fast Lightweight Peripheral Processor).

• I also find the non-secure configuration a bit confusing.

• And I’m not clear on the purpose of XIP (execute in place).

My goals for this project are:

• A GUI to control external pins

• Running a simple algorithm that generates datapoints to be sent over 4G

So here are my questions:

1. Should I just ignore the RISC-V coprocessor, or can it run tasks in parallel with the main core (like another Zephyr thread)?

2. Can Zephyr decide which core runs a given task, or do I need to manage that explicitly?

3. Regarding security, I’ll need code encryption and secure storage for 4G communication certificates. Is this something the security unit can handle?

Thanks a lot for the support!

Best regards,
Fernando Fontes

PS: I’ve already taken the training class on this MCU.

[Elfving]

Hi Fernando,

Sounds like a plan! 

I would say that I recommend doing this with a DK at first, just in case. Though you are of course free to jump straight to a custom board if you'd like to.

Should I just ignore the RISC-V coprocessor, or can it run tasks in parallel with the main core (like another Zephyr thread)?

Both. So there are a lot of customers who completely disregard the FLPR core just to avoid any extra complexity, and you are free to do that as well. Although, it is an extra core with which you can do extra tasks you might need to do. If you eg. have some tasks you would need to do in a timely fashion, and can't be delayed due to events on the main core, the FLPR might be exactly what you'd need. 

I assumed the DevAcademy would touch on how the FLPR core works, but I see that it is mainly a quiz unfortunately. We have some documentation for it here though.

Can Zephyr decide which core runs a given task, or do I need to manage that explicitly?

I guess you can also make something on the application side that distributes tasks between cores, but no that is mainly handled explicitly. You essentially have a separate image running on the FLPR.

Regarding security, I’ll need code encryption and secure storage for 4G communication certificates. Is this something the security unit can handle?

Yes, you get secure storage on the 54L15, as well as other security features.

Regards,

Elfving

[Fernando Fontes]

Thank you for the fast answer! I will take a look at your suggestions. 

[Fernando Fontes]

Hi Elfving ,

I hope you’re doing well.

Our development is now reaching a mature stage, and we’re planning to implement remote firmware updates. As mentioned earlier, the board uses a Quectel EG915 4G module for communication, and I’d like to ask for some guidance on how to build an over-the-air (OTA) update application.

I have previous experience implementing OTA updates on STM32 and ESP32 platforms using AWS IoT Core. However, most of the resources I’ve found for Nordic chips focus on Bluetooth-based FOTA.

I did come across a GitHub project targeting the nRF52840 that appears to do exactly what I need, but it relies on the legacy Nordic SDK rather than Zephyr.

Is there any updated documentation or guidance on achieving this with the newer nRF54 series?

Thank you as always for your support.

Best regards,
Fernando Fontes

[Elfving]

Hi again Fernando, 

Glad to hear that you've gotten so far in your project! 

Since the Quectel EG915 4G module is doing everything with cellular, I assume you do not need an OTA per se, but just DFU? As, from the NRF side, nothing needs to be transferred Over The Air? Let me know if I've misunderstood your set-up here.

We have lots of general documentation for DFU solutions (eg. here, here and here), as well as some mention of how it works in our DevAcademy (Exercise 1 goes through how its done over UART).

By the way, if you've gotten as far created your own custom board; note that we do offer hardware reviews, and antenna tuning for free here.

Regards,

Elfving

[Fernando Fontes]

Hi Elfving thank you for replying,

Ok, I will need to take a close look at the DFU exercise in the academy, in particular the "Dual slot DFU with swapping". 

So, the idea is to have the main app running the modem_cellular drivers from zephyr that ultimately will connect to AWS IoT Core and handle transmissions over MQTT. From there, the new firmware would be downloaded and I was thinking if I had enough flash storage I could divide it in two for storing the old application and the new application. Then reset, and the bootloader would select the new slot for booting. 

However, as plan b if I'm running out of storage, I could use the storage of the EG915 to old the new firmware file and then the bootloader would configure the UART for talking to the EG915 using AT commands and do the transfer.

What do you think? Is the Academy exercise a good starting point for this? Ideally I would have both the ability to update using the SIM card or using the BLE FOTA for clients that are not adding SIM cards.

Best regards,

Fernando Fontes

[Elfving]

If storage is a potential issue I would recommend also having a look at the nRF54LM20.

Fernando Fontes said:

Ideally I would have both the ability to update using the SIM card or using the BLE FOTA for clients that are not adding SIM cards.

But that is still for the separate device that is doing connectivity in order to update the FW? I'm just wondering if you always just want DFU over UART on the nRF.

Regards and have a good week-end,

Elfving

[Fernando Fontes]

No, 

It will be only one device. The nRF54L15 must setup the cellular_modem drivers, connect to AWS, receive the new update file, store it somewhere, mark as new update also somewhere, and then restart so that the bootloader can boot from the new image. But everything must be performed by the nRF54L15.

Isn't DFU more for programming over UART but with external devices?

Best regards,

Fernando Fontes

[Elfving]

Fernando Fontes said:

Isn't DFU more for programming over UART but with external devices?

It is. I figured that might suit your needs more, if you had another device doing everything regarding the cellular connection. Though if this just one device that changes things. How are you thinking of doing the cellular connection? The nRF54L15 doesn't have a modem.

Regards,

Elfving

[Fernando Fontes]

The EG915 is connected via UART to the nRF54L15. Then I'm using the cellular_modem device drivers from Zephyr to maintain a PPP connection (from which I can connect to AWS IoT, MQTT, e.t.c..).

So, I will need to store the file received somewhere, can be on the flash of the nRF54L15 or I can use the EG915 AT commands for storing it as a file there. Then, the bootloader, will need to change the running image.

[Elfving]

Ah I see. 

I believe there are multiple options, like you say. Going through the tutorial and docs and figuring out what would be best for you sounds like an idea. That said, storing it on the device itself does sound easiest to me.

Regards,
Elfving