nRF54L15-RISC V core use

[SubuMuthu]

Hi, 

SDK: 3.0., nRF54L15

The application is Matter + BLE dynamic multi-protocol + battery powered sleepy end device. Current Application(Matter/Thread + BLE + Firmware application) uses Cortex-M33 core, which has taken up almost 235KMB to 240KB of SRAM space and 1.1MB of flash space. 

We are releasing a  variation which involves RFID(125KHZ) and propriety implementation.  This involves specific and controlled timing for  generating 125KHZ RF signals and reading back the card contents. The Cortex-M33 core is already taxed with Matter and BLE and we are exploring the use of RISC-V core. 

The RFID application is not a large code base and it will require a) Timer/Counter, 2) ADC, 3) comparator, 4) capture compare and 5) core to manage  everything.  The RFID subsystem will periodically wake up,  generate a card detect signal, check if card is present, if present,  read the card, then go back to sleep, and wake up during the next one. The sleep - wake is every second.

There are critical timing to meet for successful card detection/reading.  It could be  possible to implement this in Cortex-M33 because the device is a sleepy(Thread) end device but we are concerned that the RFID application will not have any control on the priority(it could be allocated to Matter/Thread or BLE).  This is reason for us to look at the RISC-V core and use it exclusively.

The questions include:

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.

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?

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

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?

5)) Is it possible to use external SRAM? this is not only for RISC-V core but also for Cortex-M33 core.

Thanks.

Subu

[Susheel Nuguru]

Hi Subu,

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.

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.

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?

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

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

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.

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?

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.

5)) Is it possible to use external SRAM? this is not only for RISC-V core but also for Cortex-M33 core.

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

[Susheel Nuguru]

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.

[SubuMuthu]

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.

[Susheel Nuguru]

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