softperipheral: rev c6e66aca635e9dece5992e1f9464da81e33ed6fa

softperipheral/CHANGELOG.rst

@@ -9,6 +9,18 @@ Changelog
 
 All the notable changes to this project are documented on this page.
 
+nRF Connect SDK v3.1.0
+**********************
+
+This is a release that focuses on improving existing soft peripherals.
+See the following list of changes:
+
+
+* Bug fixes:
+
+  * Fixed higher frequency transfers for Soft Peripheral sQSPI for the nRF54L15 and nRF54H20 SoCs.
+    For details, see the :ref:`sqspi_changelog` page.
+
 nRF Connect SDK v3.0.0
 **********************
 

softperipheral/doc/introduction.rst

@@ -37,12 +37,14 @@ The following table shows which soft peripherals and their versions are supporte
    :widths: auto
    :header-rows: 1
 
-   * - soft peripheral
+   * - Soft peripheral
      - Hardware platform
-     - Versions
+     - Version
    * - sQSPI
-     - nRF54L15 SoC
-     - v0.1.0
-   * - sQSPI
-     - nRF54H20 SoC
-     - v0.1.0
+     - - nRF54L15 SoC
+       - nRF54H20 SoC
+     - - nRF54L15 SoC:
+          - v0.1.0 with NCS v3.0.0
+          - v1.0.0 with NCS v3.1.0
+       - nRF54H20 SoC:
+          - v0.1.0 with NCS v3.0.0

softperipheral/doc/sQSPI/CHANGELOG.rst

@@ -9,6 +9,23 @@ sQSPI changelog
 
 All the notable changes to sQSPI are documented on this page.
 
+v1.0.0
+******
+
+See the list of changes for the current release.
+
+.. note::
+   This release introduces a change in the API, updating the naming convention from ``nrfx_qspi2`` to ``nrf_sqspi`` prefix, which breaks backward compatibility.
+
+* Added:
+
+  * The following for nRF54L15 devices:
+
+    * Support for preparing (holding) transfers.
+    * Higher speed transfers are now supported (>=33 MHz) by using GPIOHSPADCTL.
+    * Position Independent Code for more flexibility when placing the firmware.
+    * Initial support to use with displays.
+
 v0.1.0
 ******
 

softperipheral/doc/sQSPI/README.rst

@@ -61,9 +61,9 @@ To better understand the capabilities and limitations of sQSPI, see its comparis
    :caption: Subpages:
 
    features.rst
-   nrf54L15_porting_v0_1_0.rst
-   nrf54H20_porting_v0_1_0.rst
+   nrf54L15_porting_v1_0_0.rst
+   nrf54H20_porting_v1_0_0.rst
    timing.rst
    CHANGELOG.rst
    limitations.rst
-   api_reference_v0_1_0.rst
+   api_reference_v1_0_0.rst

softperipheral/doc/sQSPI/api_reference_v0_1_0.rst → softperipheral/doc/sQSPI/api_reference_v1_0_0.rst

@@ -1,4 +1,4 @@
 API Reference
 #############
 
-.. doxygengroup:: nrfx_qspi2
+.. doxygengroup:: nrf_sqspi

softperipheral/doc/sQSPI/features.rst

@@ -99,7 +99,7 @@ The following features are supported:
    * Number of SCLK cycles for dummy data
    * Number of bytes for data
 
-  For details on how to adjust these values, see the :c:struct:`nrfx_qspi2_xfer_t` struct.
+  For details on how to adjust these values, see the :c:struct:`nrf_sqspi_xfer_t` struct.
 
 * Dual lane distribution
 

softperipheral/doc/sQSPI/limitations.rst

@@ -9,20 +9,20 @@ When working with sQSPI, you should be aware of the following limitations.
    :local:
    :depth: 2
 
-v0.1.0
+v1.0.0
 ******
 
 Refer to the following detailed descriptions of current limitations:
 
 * sQSPI does not support slave mode operations; it can only operate as a controller (master).
 * The sQSPI support for SPI half-duplex setup is implemented but not tested.
-* sQSPI SPI modes 1,2, and 3 (see the :c:var:`nrfx_qspi2_dev_cfg_t.spi_cpolpha` configuration structure) may present artifacts (delays and clock stretching) on the last SCLK cycle during a transfer.
+* sQSPI SPI modes 1,2, and 3 (see the :c:var:`nrf_sqspi_dev_cfg_t.spi_cpolpha` configuration structure) may present artifacts (delays and clock stretching) on the last SCLK cycle during a transfer.
 * The nrfx API for sQSPI does not support configuring the use of the positive or negative edge of SCLK delayed read sampling.
-* sQSPI employs the :c:var:`nrfx_qspi2_dev_cfg_t.sample_delay_cyc` parameter as an offset to FLPR's base clock counter , not SLCK clock cycles (see the :c:struct:`nrfx_qspi2_dev_cfg_t` struct).
-* sQSPI :c:var:`nrfx_qspi2_dev_cfg_t.sample_delay_cyc` has a limit:
+* sQSPI employs the :c:var:`nrf_sqspi_dev_cfg_t.sample_delay_cyc` parameter as an offset to FLPR's base clock counter , not SLCK clock cycles (see the :c:struct:`nrf_sqspi_dev_cfg_t` struct).
+* sQSPI :c:var:`nrf_sqspi_dev_cfg_t.sample_delay_cyc` has a limit:
 
   .. math::
-     nrfx\_qspi2\_dev\_cfg\_t.sample\_delay\_cyc <= \frac{FLPR_base_freq}{2*nrfx\_qspi2\_dev\_cfg\_t.sck\_freq\_khz} - 1
+     nrf\_sqspi\_dev\_cfg\_t.sample\_delay\_cyc <= \frac{FLPR_{base\_freq}}{2*nrf\_sqspi\_dev\_cfg\_t.sck\_freq\_khz} - 1
 
 * Implementation of sQSPI quad or dual lane for command transmission (for example, ``2_2_2`` and ``4_4_4`` modes) is implemented but has not been tested.
-* sQSPI does not support a configurable pin for the CSN line; only **PIN 5** is supported (see :c:var:`nrfx_qspi2_dev_cfg_t.csn_pin`).
+* sQSPI does not support a configurable pin for the CSN line; only **PIN 5** is supported (see :c:var:`nrf_sqspi_dev_cfg_t.csn_pin`).

softperipheral/doc/sQSPI/nrf54H20_porting_v0_1_0.rst → softperipheral/doc/sQSPI/nrf54H20_porting_v1_0_0.rst

@@ -31,16 +31,16 @@ This structure shows the relevant files and directories in the `sdk-nrfxlib`_ re
           │   │   └── nrf_qspi2.h
           │   ├── nrf54h20
           │   │   ├── sqspi_firmware.h
-          │   │   ├── sqspi_firmware_v0.1.0.h
+          │   │   ├── sqspi_firmware_v1.0.0.h
           │   │   └── ...
+          │   ├── nrf_config_sqspi.h
           │   ├── nrf_sp_qspi.h
-          │   ├── nrfx_config_qspi2.h
-          │   ├── nrfx_qspi2.h
+          │   ├── nrf_sqspi.h
           └── src
               └── nrfx_qspi2.c
 
 .. note::
-   The main interface for sQSPI is the :file:`nrfx_qspi2.h` file.
+   The main interface for sQSPI is the :file:`nrf_sqspi.h` file.
 
 Header files
 ============
@@ -69,18 +69,19 @@ The following list is a detailed breakdown of the necessary paths:
          #ifndef NRFX_CONFIG_H__
          #define NRFX_CONFIG_H__
 
-         #include "softperipheral_regif.h" // To Resolve correct VPR IRQn for the SoC.
-         #define nrfx_qspi2_irq_handler        SP_VPR_IRQHandler
-
-         #define NRFX_QSPI2_ENABLED            (1)
-         #define NRFX_QSPI2_MAX_NUM_DATA_LINES (4)
+         #define nrf_sqspi_irq_handler        SP_VPR_IRQHandler
+
+         #define NRF_SQSPI_ENABLED            (1)
+         #define NRF_SQSPI_MAX_NUM_DATA_LINES (4)
+         #define NRF_SQSPI_SP_FIRMWARE_ADDR 0x2f890200
+         //^ This address is user defined, the location for the sQSPI firmware
 
          #endif // NRFX_CONFIG_H__
 
 Compiling source files
 ======================
 
-For an sQSPI application to function properly, you must compile the driver implementation from the source file :file:`nrfx_qspi2.c`.
+For an sQSPI application to function properly, you must compile the driver implementation from the source file :file:`nrf_sqspi.c`.
 
 Application core and FLPR configuration
 ***************************************
@@ -202,7 +203,7 @@ The following options are available, assuming that the FLPR core has access to t
 
 .. note::
    sQSPI driver provides a default GPIO configuration and multiplexing.
-   You can apply this setup by setting :c:var:`nrfx_qspi2_cfg_t.skip_gpio_cfg` and :c:var:`nrfx_qspi2_cfg_t.skip_pmux_cfg` to ``false``.
+   You can apply this setup by setting :c:var:`nrf_sqspi_cfg_t.skip_gpio_cfg` and :c:var:`nrf_sqspi_cfg_t.skip_pmux_cfg` to ``false``.
 
 Configuring pins
 ================
@@ -211,9 +212,9 @@ In some cases you might have to modify the sQSPI driver configuration.
 For example, when changing pin drive strength to guarantee signal integrity for a new PCB design.
 You must address these cases on the sQSPI application code:
 
-* If you set the :c:var:`nrfx_qspi2_cfg_t.skip_gpio_cfg` variable to ``true``, the GPIO configuration is not managed by the sQSPI driver and it must be manually handled by the application. 
+* If you set the :c:var:`nrf_sqspi_cfg_t.skip_gpio_cfg` variable to ``true``, the GPIO configuration is not managed by the sQSPI driver and it must be manually handled by the application. 
   This is a requirement for the nRF54H20 device.
-* If you set the :c:var:`nrfx_qspi2_cfg_t.skip_pmux_cfg` variable to ``true``, the GPIO multiplexing is not managed by the sQSPI driver and it must be manually handled by the application. 
+* If you set the :c:var:`nrf_sqspi_cfg_t.skip_pmux_cfg` variable to ``true``, the GPIO multiplexing is not managed by the sQSPI driver and it must be manually handled by the application. 
   This is a requirement for the nRF54H20 device.
 
 GPIO multiplexing must be handled by setting the correct ``CTRLSEL`` value in UICR.
@@ -226,17 +227,32 @@ RAM configuration
 *****************
 
 The sQSPI Soft Peripheral operates from RAM.
+
+.. note::
+   Starting from sQSPI 1.0.0, Position Independent Code (PIC) is supported.
+   This allows an application to determine where to load the Soft Peripheral firmware.
+   The start address default value is defined in the :file:`nrf_config_sqspi.h` file but you can override it, for example, in :file:`nrfx_config.h`.
+   Start address has been verified to work as described in the provided example configuration for :file:`nrfx_config.h` and is ready for production, while other locations should be considered experimental.
+
 Your build environment must reserve the required RAM and ensure that it is readable and writable by both the application core and the FLPR core.
 This table details the memory region, it should be non-cacheable:
 
 .. list-table:: RAM Configuration Table
    :widths: auto
    :header-rows: 1
 
-   * - Start Address
+   * - Component
+     - Address offset
      - Size
-   * - 0x2f890000
-     - 0x4000
+   * - sQSPI firmware
+     - `NRF_SQSPI_SP_FIRMWARE_ADDR`
+     - 0x3740
+   * - sQSPI RAM
+     - `NRF_SQSPI_SP_FIRMWARE_ADDR` + 0x3740
+     - 0x600
+   * - Context saving
+     - 0x2f890000
+     - 0x200 (but the entire block should be retained)
 
 The build environment described in the :ref:`nrf54h20_porting_guide_code` section must comply with these requirements.
 This includes proper settings in linker scripts, device tree specifications (DTS), and resource allocation.