• State Verified Answer
  • Replies 2 replies
  • Subscribers 87 subscribers
  • Views 358 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 353738
Options

nRF51LM20 QFN52 SWO pin not assigned

Brutus

Hi,

We are currently using the nRF54L15 QFN48 package, and have the SWO pin routed to our serial debugging interface. I was reviewing the nRF54LM20 QFN52 package documentation as a possible replacement as we would need the extra GPIO pins and would like to add USB capability, and saw that the SWO pin on the LM20 is only assigned in the CSP98 package. What would be the reasoning for not assigning the SWO pin in the QFN52 package ? Would there be a possible workaround to have something similar to the SWO on an other pin ?

Thank you in advance for your time.

Best regards,

Federico

Parents
  • +1

    Hi there,

    So I use the Xiao nRF54L15 with the CSP47 talk about no Extra pins..Sweat smile Any way Here is why...

    The absence of the SWO (Serial Wire Output) pin on the nRF54LM20 QFN52 package, while present on the larger CSP98 package, is a result of pin multiplexing and the physical pin constraints of the smaller package. To accommodate extra GPIOs and USB capability within the limited pin count of the QFN52, certain less critical or optional debugging features like SWO are not assigned to a dedicated physical pin. 
    Reasoning for the unassigned SWO pin
    • Pin Limitations: The QFN52 package has a fixed number of physical pins. When adding new features like USB (which requires dedicated D+ and D- pins) and increasing the general-purpose I/O count compared to the nRF54L15 QFN48, the available pins for optional debugging interfaces become limited.
    • Pin Multiplexing: Modern MCUs use pin multiplexing (pin-muxing) to assign different peripheral functions to the same physical pin. In the QFN52 package, the pin that would normally be assigned the SWO function might be shared by other essential peripherals (like the USB or additional GPIOs), and the designers chose to prioritize those other functions for this package variant.
    • SWO is an Optional Debugging Aid: The SWO pin is used for receiving trace and log data (printf-style debugging) from the device via the Serial Wire Viewer (SWV) or Embedded Trace Macrocell (ETM) features. It is not essential for basic debugging operations like programming, halting, and single-stepping the CPU, which only require SWD (Serial Wire Debug) which uses SWDIO and SWCLK pins. 
    Workaround to have something similar to SWO
    While you cannot have a dedicated SWO pin on the nRF54LM20 QFN52 package, you can use alternative methods to achieve similar debugging functionality: 
    • RTT (Real Time Transfer): This is the most common and recommended alternative to SWO for Nordic devices. RTT is a proprietary Segger technology that uses the standard SWD interface (SWDIO and SWCLK pins) to transfer data between the target MCU and the debugger. It is often faster than SWO, does not require a dedicated pin, and supports multiple data channels for both up-link (target to host) and down-link (host to target) communication. Most modern development environments and the nRF Connect SDK have full support for RTT.
    • UART (Universal Asynchronous Receiver-Transmitter): You can configure one of the available GPIO pins as a standard UART TX pin and use it to send debug messages to your host PC via a USB-to-serial converter. This approach uses two pins (TX and potentially RX if two-way communication is needed) and is slower than RTT, but offers a simple, universally compatible method of outputting data.
    • LED/GPIO Toggling: For simple debugging scenarios, toggling a GPIO pin or an LED can signal different states in the code. 
    For your application, transitioning from SWO on the nRF54L15 to RTT on the nRF54LM20 would be the most seamless and performant solution, as it requires minimal hardware changes (only the standard SWD connection) and provides robust logging capabilities.
    I'm waiting on the LM20A, curious how the onboard usb-c works out.
    HTH
    GL :) PJ  V
Reply
  • +1

    Hi there,

    So I use the Xiao nRF54L15 with the CSP47 talk about no Extra pins..Sweat smile Any way Here is why...

    The absence of the SWO (Serial Wire Output) pin on the nRF54LM20 QFN52 package, while present on the larger CSP98 package, is a result of pin multiplexing and the physical pin constraints of the smaller package. To accommodate extra GPIOs and USB capability within the limited pin count of the QFN52, certain less critical or optional debugging features like SWO are not assigned to a dedicated physical pin. 
    Reasoning for the unassigned SWO pin
    • Pin Limitations: The QFN52 package has a fixed number of physical pins. When adding new features like USB (which requires dedicated D+ and D- pins) and increasing the general-purpose I/O count compared to the nRF54L15 QFN48, the available pins for optional debugging interfaces become limited.
    • Pin Multiplexing: Modern MCUs use pin multiplexing (pin-muxing) to assign different peripheral functions to the same physical pin. In the QFN52 package, the pin that would normally be assigned the SWO function might be shared by other essential peripherals (like the USB or additional GPIOs), and the designers chose to prioritize those other functions for this package variant.
    • SWO is an Optional Debugging Aid: The SWO pin is used for receiving trace and log data (printf-style debugging) from the device via the Serial Wire Viewer (SWV) or Embedded Trace Macrocell (ETM) features. It is not essential for basic debugging operations like programming, halting, and single-stepping the CPU, which only require SWD (Serial Wire Debug) which uses SWDIO and SWCLK pins. 
    Workaround to have something similar to SWO
    While you cannot have a dedicated SWO pin on the nRF54LM20 QFN52 package, you can use alternative methods to achieve similar debugging functionality: 
    • RTT (Real Time Transfer): This is the most common and recommended alternative to SWO for Nordic devices. RTT is a proprietary Segger technology that uses the standard SWD interface (SWDIO and SWCLK pins) to transfer data between the target MCU and the debugger. It is often faster than SWO, does not require a dedicated pin, and supports multiple data channels for both up-link (target to host) and down-link (host to target) communication. Most modern development environments and the nRF Connect SDK have full support for RTT.
    • UART (Universal Asynchronous Receiver-Transmitter): You can configure one of the available GPIO pins as a standard UART TX pin and use it to send debug messages to your host PC via a USB-to-serial converter. This approach uses two pins (TX and potentially RX if two-way communication is needed) and is slower than RTT, but offers a simple, universally compatible method of outputting data.
    • LED/GPIO Toggling: For simple debugging scenarios, toggling a GPIO pin or an LED can signal different states in the code. 
    For your application, transitioning from SWO on the nRF54L15 to RTT on the nRF54LM20 would be the most seamless and performant solution, as it requires minimal hardware changes (only the standard SWD connection) and provides robust logging capabilities.
    I'm waiting on the LM20A, curious how the onboard usb-c works out.
    HTH
    GL :) PJ  V
Children
Related
Terms of service