softperipheral: rev 7262e00b5f72fd04b8e0c9b92b743d907b9a106b

Using new naming convention: nrfx_qspi2 -> nrf_sqspi
Using sQSPI 0.2.0 firmware (which now uses PIC)
Deleting old driver files

Signed-off-by: Luis David Lopez <[email protected]>

Author: lopeztel

softperipheral/CHANGELOG.rst

@@ -20,3 +20,15 @@ See the following list of changes:
 
   * The first implementation of Soft Peripheral sQSPI for the nRF54L15 and nRF54H20 SoCs.
     For details, see the :ref:`sqspi_changelog` 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.

softperipheral/doc/introduction.rst

@@ -40,9 +40,20 @@ The following table shows which soft peripherals and their versions are supporte
    * - soft peripheral
      - Hardware platform
      - Versions
+     - NCS version
    * - sQSPI
      - nRF54L15 SoC
      - v0.1.0
+     - v3.0.0
+   * - 
+     - 
+     - v0.2.0
+     - v3.1.0
    * - sQSPI
      - nRF54H20 SoC
      - v0.1.0
+     - v3.0.0
+   * - 
+     - 
+     - v0.2.0
+     - v3.1.0 (experimental)

softperipheral/doc/sQSPI/CHANGELOG.rst

@@ -20,3 +20,15 @@ This is an initial release.
   * Configurable :ref:`clock phase and polarity<sqspi_features_clock_phase>`.
   * :ref:`Delayed read sampling <sqspi_features_read_sampling>`.
   * Support for :ref:`various packet formats <sqspi_features_packet_formats>`.
+
+v0.2.0
+******
+
+This is an improvement release.
+
+* 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.

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_v0_2_0.rst
+   nrf54H20_porting_v0_2_0.rst
    timing.rst
    CHANGELOG.rst
    limitations.rst
-   api_reference_v0_1_0.rst
+   api_reference_v0_2_0.rst

softperipheral/doc/sQSPI/api_reference_v0_1_0.rst renamed to softperipheral/doc/sQSPI/api_reference_v0_2_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
+v0.2.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 renamed to softperipheral/doc/sQSPI/nrf54H20_porting_v0_2_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_v0.2.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,27 @@ RAM configuration
 *****************
 
 The sQSPI Soft Peripheral operates from RAM.
+
+.. note::
+   Starting from sQSPI 0.2.0, PIC (Position Idependent Code is supported), which means that an application will decide where to load the SP firmware.
+   This is start address is defined in :file:`nrf_config_sqspi.h` and set in :file:`nrfx_config.h` 
+
 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
+   * -
+     - Address offset
      - Size
-   * - 0x2f890000
+   * - sQSPI Firmware
+     - `NRF_SQSPI_SP_FIRMWARE_ADDR`
      - 0x4000
+   * - 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.