BL54L10 Series - Bluetooth LE + 802.15.4 + NFC

Port 0 (Low power domain) and Port 1 (Peripheral Domain) I/O pins allow for enabling GPIOs to generate events on pin state change with one of the following input conditions:

• Rising edge

• Falling edge

• Any change

These two ports also allow I/O pins to wake the system from System OFF or System ON as well as being configured for GPIO Sense/Detect.

Port 2 (MCU Domain) does not allow Events to be generated on its GPIO pins and cannot wake the system from sleep. P2 does not have the GPIO SENSE or DETECT mechanism.

The following table lists the BL54L ports capabilities.

For further details refer to GPIO Port Capabilities.

On the nRF54L15 (as well as L10 and L05), peripheral instances that share the same ID and base address (e.g., SPIM00, SPIS00, TWIM00, UARTE00, all mapped to the same ID) cannot be used simultaneously. You must disable one peripheral before enabling another on that same ID, specifically clearing the peripheral's ENABLE register.

Here is a breakdown of simultaneous usage, restrictions, and shared resources based on the nRF54L15 architecture:

Peripherals That Cannot Be Used Simultaneously

• Shared Instance ID Peripherals: Peripherals with the same ID, such as SPI00, SPIM00, SPIS00, TWI00, TWIM00, TWIS00, and UARTE00 (collectively 00), are mutually exclusive. Only one can be active at a time.
• Pin-Colliding Peripherals: If two peripherals are assigned to the same GPIO pin through the PSEL register, they cannot operate simultaneously.
• QSPI/SPIM00 Limitations: While sQSPI (soft QSPI) and SPIM00 can often coexist, they cannot share the same pins, and on some configurations, the QSPI CSN pin is shared with the SPIM CSN, preventing simultaneous operation.
• Radio and High-Speed Peripherals: While high-speed UARTE (up to 4 Mbps) and SPIM (up to 32 MHz) can run simultaneously with other peripherals, extreme bus traffic may impact real-time performance.

Peripherals That Can Be Used Simultaneously

• Different Instances: You can run multiple instances of similar peripherals simultaneously if they have different IDs (e.g., UARTE20 and UARTE00 can run at the same time, as they are in different power domains).
• Dedicated Peripherals: Peripherals with unique IDs in the address map (e.g., QSPI and ADC, or Timers and PWM) can generally be used at the same time.
• VPR Core (FLPR) and Main CPU: The FLPR (Fast Lightweight Peripheral Processor) can handle specific peripherals (like I2C/SPI) in parallel with the main ARM Cortex-M33 processor.
• DPPI (Distributed Programmable Peripheral Interconnect): You can connect events and tasks between multiple independent peripherals without CPU intervention.

Key Limitations and Rules

• Power Domains: Peripherals with numeric IDs starting with 2 (e.g., UARTE20) are in the Peripheral domain (16 MHz), while those with 0 (e.g., UARTE00) are in the MCU domain (128 MHz). Mixing them generally allows for concurrent operation.
• P2 Port Conflict: The Peripheral domain uses dedicated GPIO Port 2 (P2). If multiple peripherals are assigned to the same P2 pins, they will conflict.
• Switching Rule: To switch between two peripherals sharing an ID:
  • Disable the previously used peripheral.
  • Disable any DPPI channel connections.
  • Clear all bits in the INTEN register.
  • Configure the new peripheral. 

GPIO Pin Mapping

• Basic rule is that peripheral instances of a certain power domain can only be mapped to the GPIO port of this power domain e.g., SPIM00 or UARTE00 can only be mapped to GPIO P2 (see block diagram at https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/overview.html)
• Some peripherals allow for "cross power-domain usage" e.g., UARTE20/21 would usually go to P1 but can connect across power domains to dedicated pins on P2.
• It's mainly about following the rules in this section of the data sheet: https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/pin.html

Python scripts can only be loaded onto a Canvas enabled device via serial interface such as UART or USB. Canvas FW is programmed over SWD programming interface only.

Ensure your custom hardware design has provisions for both SWD for Canvas FW programming and serial for loading python scripts.

Review the README.md of the canvas_python_firmware repository (https://github.com/Ezurio/canvas_python_firmware) for the hardware platform to locate the "Default REPL port"

When building an application in nRF Connect for VS Code you must add a build configuration, which includes selecting the board target that your application will be run on. When working with Ezurio's BL54L15, BL54L15u, or BL54L10 you should select the board as follows:

1) Click the in the field for the target board selection and type, "BL54 " to reduce the number of board targets listed to only the BL54 series of boards.

The board file variant selects the CPU core and security model the build will target. On the 54 Series you will see variants such as cpuapp, cpuapp/ns, cpuflpr, and cpuflpr/xip

cpuapp:

Refers to the application core, where Zephyr application firmware is run.  This selection builds for the app core with security features enabled (Trust Zone Secure).

*This build is recommended for most use cases.

cpuappns:

This variant builds a non-secure application image which runs alongside a secure image on Trust Zone-enabled devices where the the application core is partitioned into a secure domain and non-secure domain. The secure image is usually generated by Trusted Firmware-M or a secure bootloader).
This is typically used when developing the main application, while the secure firmware handles crypto keys and secure services.

cpuflpr:

Refers to builds for the network core also known as the Fast Lightweight Processor (flpr).

The network core is usually dedicated to the radio stack (BLE, 802.15.4, etc)

This build is typically used to add custom firmware directly on the network core, instead of using Nordic's precompiled controller firmware.

cpuflpr/xip:

The /xip variant means execute in place

This image is built to run directly from external flash, rather than being copied to RAM.

This is useful if the core firmware is too large to fit into RAM, or if it is desired to save RAM usage by running the code directly from flash. 

When working with the BL54L15 DVK or BL54L15u DVK most use cases should select bl54l15_dvk/nrf54l15/cpuapp.

NOTE: When developing with the BL54L15 DVK for an application that will run on the BL54L10 module it is recommended that you select bl54l15_dvk/nrf54l10/cpuapp. This variant enforces the reduced memory constraints that apply when working with the BL54L10.

The nRF54L15 BLE MCU used on the BL54L15 does not include an Audio PLL making it only possible to be used in a limited number of applications. The Audio PLL is used for isochronous channel synchronization for L and R streams meaning True Wireless Stereo (TWS) can’t be supported. However, other applications that do not need this may be able to use the BL54L15 in an Audio solution.