Introducing the RISC-V coprocessor of the nRF54L Series/nordic/nordic-blog/b/blog/posts/introducing-the-risc-v-coprocessor-of-the-nrf54l-seriesThe nRF54L Series SoCs features a RISC-V coprocessor, enabling efficient, flexible designs with enhanced performance and ultra-low-power wireless connectivity.en-USTelligent Community 13RE: Introducing the RISC-V coprocessor of the nRF54L Serieshttps://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/introducing-the-risc-v-coprocessor-of-the-nrf54l-seriesWed, 29 Apr 2026 18:03:14 GMT137ad170-7792-4731-bb38-c0d22fbe4515:96178cd0-b95e-4087-98ad-e8a6d49c3ec5ujur0070<p><span>Hello!, I have a custom PCB where I have meshed up the spi00 pins by interchanged MISO/MOSI lines. Can RISC-V processor come to rescue? .</span></p> <div style="clear:both;"></div><img src="https://devzone.nordicsemi.com/aggbug?PostID=1551&AppID=4&AppType=Weblog&ContentType=0" width="1" height="1">RE: Introducing the RISC-V coprocessor of the nRF54L Serieshttps://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/introducing-the-risc-v-coprocessor-of-the-nrf54l-seriesWed, 01 Apr 2026 22:18:38 GMT137ad170-7792-4731-bb38-c0d22fbe4515:96178cd0-b95e-4087-98ad-e8a6d49c3ec5Sebastian Viviani0<p>Hi Jack,<br />&nbsp; &nbsp; probably best to create a support ticket for this, as this seems to be something related to sysbuild.</p><img src="https://devzone.nordicsemi.com/aggbug?PostID=1551&AppID=4&AppType=Weblog&ContentType=0" width="1" height="1">RE: Introducing the RISC-V coprocessor of the nRF54L Serieshttps://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/introducing-the-risc-v-coprocessor-of-the-nrf54l-seriesThu, 26 Mar 2026 09:26:56 GMT137ad170-7792-4731-bb38-c0d22fbe4515:96178cd0-b95e-4087-98ad-e8a6d49c3ec5Jack jpeng0<p>Hello! I&rsquo;m currently looking to use the M33 on the nRF54L15 for range-finding calculations, whilst the RISC-V VPR coprocessor handles some feature processing. I&rsquo;m currently using NCS v3.2.1, and I&rsquo;ve built two images. The one below is for the RISC-V VPR coprocessor; here is the CMake file for RISV.</p> <pre class="ui-code" data-mode="text"># uwb_merge/sysbuild.cmake cmake_minimum_required(VERSION 3.20.0) ExternalZephyrProject_Add( APPLICATION cpuflpr SOURCE_DIR ${APP_DIR}/cpuflpr BOARD nrf54l15dk/nrf54l15/cpuflpr BUILD_ONLY y ) add_dependencies(${DEFAULT_IMAGE} cpuflpr)</pre> <p>Currently, the PM script continues to add `cpuflpr` to the `--images` list, even though there is no corresponding entry in `partitions.yml`, causing the Python script to crash. (The `BUILD_ONLY y` option does not take effect in the `partition_manager.cmake` file for NCS v3.2.1.) The purpose of `BUILD_ONLY y` is to allow sysbuild to compile this image, but not to hand it over to the Partition Manager for management; instead, cpuapp is responsible for loading it into SRAM and booting it at runtime. Is there a good solution to fix this?<br /><br /></p> <div style="clear:both;"></div><img src="https://devzone.nordicsemi.com/aggbug?PostID=1551&AppID=4&AppType=Weblog&ContentType=0" width="1" height="1">