nRF54L15-RISC V core use

RE: nRF54L15-RISC V core use

Susheel Nuguru — Tue, 13 May 2025 06:48:31 GMT

Sorry for delayed response Subu,

I am not an expert at this configuration but maybe we need to use the right pm_static setup for the sysbuild+Matter.FLPR

It might help to rename/delete pm_static_nrf54l15dk_nrf54l15_cpuapp_ns.yml in your project folder and add the app: FLPR memory section section in the pm_static_nrf54l15dk_nrf54l15_cpuflpr.yml (after creating one) instead

Open pm_static_nrf54l15dk_nrf54l15_cpuflpr.yml and add something like below or the one that matches your memory layout if it is different

app:
  region: sram_remote
  size: 0x20000

Make sure you are using sysbuild and then add this to your CMakeLists.txt file

if(CONFIG_SYSBUILD)
  sysbuild_add_child(app
    SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
    DOMAIN app
  )
  sysbuild_add_child(remote
    SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/remote
    DOMAIN remote
  )
endif()

as shown in the second part of that change, add folder "remote" in your project folder and add a file "domain.yml" inside the remote folder and add this below content to that yml file

build_by_default: true

The folder structure should be something like this after the changes

root/
├── prj.conf
├── CMakeLists.txt         ← With sysbuild_add_child
├── pm_static_nrf54l15dk_nrf54l15_cpuflpr.yml  ← This is important
├── remote/
│   ├── domain.yml
│   ├── src/
│   │   └── main.c
│   └── CMakeLists.txt     ← For FLPR build

RE: nRF54L15-RISC V core use

SubuMuthu — Tue, 06 May 2025 16:03:07 GMT

Thank you Susheel.

As of now, I am able to make the IPC Service example(ipc/icmsg backend) work with nrf54l15dk/nrf54l15/cpuapp.

/opt/nordic/ncs/v3.0.0/zephyr/samples/subsys/ipc/ipc_service/icmsg

I am able to make the FLPR core to work with ADC, Timer, etc.

As I mentioned, the goal is integrate with Matter door lock. I copied the zephyr/samplessubsys/ipc/ipc_service/icmsg source files to Matter door lock and tried to build as a starting point. Please see below picture for folder structure.

The remote code was moved from icmsg code.

nordic-flpr snippet is included.

When I tried to build the matter door lock sample + the flpr, I get the below build error.

Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'settings_storage' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: No compatible parent partition found for app
Failed to partition region sram_primary, size of region: 163840
Partition Configuration:
vpr_launcher_sram:
  placement:
    before:
    - app
  size: 163840

CMake Error at /opt/nordic/ncs/v3.0.0/nrf/cmake/sysbuild/partition_manager.cmake:181 (message):
  Partition Manager failed, aborting.  Command:

Can you please with this? If I am able to integrate the Matter door lock sample and ICMSG samples, i can take it further on my own.

The Nordic website does not provide much information so help is appreciated.

Thanks.

RE: nRF54L15-RISC V core use

Susheel Nuguru — Tue, 06 May 2025 11:31:20 GMT

Regarding my answer on point 1). I might be wrong I have got some info that the datasheet and SDK documentation will get more updates related to VPR soon. And there will be more information on the shared peripherals. Until then I do not have much info that I can share on that matter apart from what I have shared already.

RE: nRF54L15-RISC V core use

Susheel Nuguru — Tue, 06 May 2025 06:59:30 GMT

Hi Subu,

[quote user=""]1. Does the RISC-V core have access to ADC, Timer/Counter, Capture compare and comparator? This link(https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/vpr_flpr.html) does not show that.[/quote]

No, it does not seem that you could use VPR only to run the RFID as ADC does not seem to be accessible through this core. I think you need to design some IPC mechanism where peripheral events are listened on the Cortex-M33 core and processed on the VPR through IPC. That way there is minimal overhead for M33 due to this and most of the info when passed to VPR can then process the data.

[quote user=""]2. Can the RISC-V core be put into sleep mode and be woken up by peripherals (like when Card is detected? Or can it sleep and wake up periodically?[/quote]

Yes, VPR can go to low power states and can be woken up with some limited wakeup sources like mapped GPIO, mailbox interrupt.

[quote user=""]3)) Any sample examples other than this - https://github.com/nrfconnect/sdk-zephyr/tree/v3.7.99-ncs1/samples/subsys/ipc.[/quote]

Unfortunately No, I have been using this sample also as template for some of my other hobby experiments. there is a sample in nrf/samples/ipc/ipc_service but this seems to have been tested only on nRF53 and nRF54H. But My best guess is that this should also work fine on nRF54L.

[quote user=""]4) What about the SRAM requirements? we are running low but we are not expecting large SRAM use. We are thinking of XIP(RRAM).So would it have any performance impacts due to Cortex-M33 and RISC-V contention? If SRAM is used, how much of SRAM is needed?[/quote]

RRAM is slow, and if you say that you are taking all this effort because you think there are some time critical nature for the RFID design, then maybe RRAM might not be the best choice. How much of SRAM is needed is difficult for me to say as this is varies for every application and there is no generic answer to that. Just compile your application and look at the .map file to get an idea. I am thinking that if your RFID is a bit more complex than a simplistic RFID then it should be needing around 40KB of SRAM.

[quote user=""]5)) Is it possible to use external SRAM? this is not only for RISC-V core but also for Cortex-M33 core.[/quote]

Yes, both cores can use external memory using QSPI but the execution of these XIP might have some performance issues depending on SPI clock speed, Memory latency Arbitration between cores and Bus congestion during BLE/Matter radio activity