UARTE21 and SMP Bluetooth conflict on nRF54L15 – works only with debugger attached

[Agustin Perez]

Hi,

I'm working with the nRF54L15 SoC and running into an issue when using UARTE21 together with SMP over Bluetooth. Here's what I’ve observed:

• UARTE21 works perfectly when Bluetooth is disabled.

• After starting BLE advertising using start_smp_bluetooth_adverts(), the UART output becomes corrupted and then freezes completely.

• However, when running the same firmware with a debugger attached (using J-Link with VSCode), both UART and Bluetooth work fine simultaneously.

This is how I'm starting the Bluetooth SMP advertising:

#ifdef CONFIG_MCUMGR_TRANSPORT_BT
start_smp_bluetooth_adverts();
#endif

And here is a sample of the console output without the debugger (it freezes after this output):

uart:~$ ▒+)%%%HU▒Z▒▒
@▒▒ ▒▒▒C:3[m▒Y9▒▒▒▒▒▒[▒p▒▒-
1▒▒▒▒)R▒▒&

Some relevant parts of my prj.conf:

CONFIG_CLOCK_CONTROL_NRF=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n

Additionally, based on advice from other tickets ( UARTE21 and SPIM20 on P2 issues ) , I’ve added the following code line in my application:

// Force constant latency mode
NRF_POWER->TASKS_CONSTLAT = 1;

Some conclusions:

• This issue does not occur when using UART00—it appears to be specific to UARTE21. However, I need to use UARTE21 because the application requires SPI00.

• A clear behavioral difference exists when running the application with vs. without a debugger.

We’re approaching pre-production, so resolving this issue is a top priority. Any insights, workarounds, or guidance on how to get UARTE21 working alongside Bluetooth SMP would be extremely helpful.

Thanks.

[khelmutlord]

Could you share the pins you are using for SPI00 and UARTE21?

[Håkon Alseth]

Hi,

Thank you so much for providing a detailed and proper overview of the issue that you are seeing.

Agustin Perez said:

I'm using P2.07 and P2.08 for UARTE21

When crossing domains, ie. using P2 pins on UARTE2x (and TWIM2x/SPIM2x), there is a requirement to enable constant latency mode:

 RE: nRF54L15: UART pinout not working unless connecting the RTT viewer 

 

This is unfortunately not documented yet from our side, but will be in the future. My deepest apologies for the inconvenience this is causing you. I will also convey internally that this will need driver transport logic added.

 

Kind regards,

Håkon

[Agustin Perez]

Hi, 

I’ve added the following line:

// Set register
NRF_POWER->TASKS_CONSTLAT = 1;

However, the issue still persists. The UART works correctly when BLE is not enabled, but once advertising starts, the UART stops working or freezes.

Do you have any idea what might be causing this behavior?

[Håkon Alseth]

Hi,

 

Thank you for your patience in this matter and confirming that CONSTLAT is indeed set. I have been able to reproduce this with the smp_svr sample, by enabling UARTE21, and see that the uart output is corrupted just as you mention.

 

I have reported this internally and alerted the team(s) in question.

 

Kind regards,

Håkon

[Agustin Perez]

Hi,

Thank you for your prompt follow-up and for reproducing the issue on your end.

As we are approaching production soon, I would greatly appreciate it if you could keep me informed of any updates or findings related to this issue. If a workaround becomes available, please do let me know.

Thank you again for your support.

[Einar Thorsrud]

Hi,

On the nRF54L15, the Bluetooth stack (specifically MPSL) will disable constant latency mode unless it is enabled in a way it knows about. Therefor, CONFIG_SOC_NRF_FORCE_CONSTLAT=y  will not work in this case.

To use constant latency with Bluetooth, you can add CONFIG_NRFX_POWER=y to prj.conf and enable constant latency using nrfx_power_constlat_mode_request().