UART reception on nRF54L10 not working reliably without RTT Viewer or debugger attached.

[Paul Vogel0]

I am using the nRF54L10 on a custom board with a couple of LEDs, a flash storage device and a GNSS device.  The application wakes periodically to gather fix information from the GNSS and store the info to flash.  The application works correctly and reliably as long as the RTT viewer or debugger is attached.

Without the viewer connected, watching the UART data with a logic analyzer shows the GNSS is sending valid fix information, but the application never sees the fix information because the gnss_data_callback function is never called.  I added an echoed UART output that copies received bytes out through a test point, and only a small fraction of the GNSS message bytes are being echoed out, presumably because they are not being received correctly.

I originally created a ticket in the Zephyr forum for this that has more details on the things that have been tried and results:

https://github.com/zephyrproject-rtos/zephyr/issues/103005

[Vidar Berg]

Hello,

Thanks for creating a new ticket. Please check if your uart instance and the GPIO port assigned to it reside in different power domains or not. Using a peripheral with a port from another power domain is referred to as Cross power-domain use in the DS and is only supported for selected pins and not in the lowest power mode. The reason I am asking is that when you connect the RTT Viewer, the chip enters debug interface mode and in this mode, all power domains remain powered on during sleep. Which in this case is equivalent to using the constant latency sub power mode mentioned in the linked section in the datasheet.

Similar case: https://devzone.nordicsemi.com/f/nordic-q-a/126270/nrf54l15-spi-corruption-on-gpio2-p2-when-rtt-is-disconnected/557576 

Best regards,

Vidar

[Paul Vogel0]

That sounds like a plausible cause, but I think the pin / uart selection for this are in the same power domain.  We are using the QFAA package.  The output from the GNSS arrives on P2.07 and is sent to GNSS from P2.08.  uarte21 is being used for tor interface

Is there any chance the TRACEDATA functions could be interfering?

[Vidar Berg]

UARTE21 and P2 are actually in different domains (the numbering can be a bit confusing) and this matches the behaviour you're observing. The solution is to request the constant latency power mode while the UARTE is enabled as described here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/pinmap.html#managing_cross_power-domain_pin_mapping 

[Paul Vogel0]

Thanks!!!! this was the problem.  I would have sworn I saw some place where the docs said that uart21 and P2.07 & P2.08 were in the same power domain.  Can you tell me where that information is at?

As far as I'm concerned now, this ticket can be closed.

[Vidar Berg]

Excellent, thanks for confirming what the issue was! This is documented in the "Pin Assigments" chapter of the data sheet: https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/pin.html. This also includes the Cross power-domain use section linked to earlier.

I would also recommend you have a look at this devacademy course at https://academy.nordicsemi.com/courses/nrf54l-series-express-course/lessons/lesson-2-power-domains-event-system-and-gpio/ which explains why we have this architecture.