Connect cross power-domain to UART00 on P2 of nRF54L15 DK

[Archiet]

Hi there!

May I know how to have UART00 on P2 like what is shown below as I wanted to have higher speed.

Is it the same as other UART assignments on P0 and P1?

Thanks!

[Edvin]

Hello,

Please see the cross power-domain section of the pin assignment documentation for the nRF54L15.

What pins specifically are you trying to use? Have you used a logic analyzer to see if any of the pins are doing anything? 

Best regards,

Edvin

[Archiet]

Hi there!

I have read the link you shared before. I know it mentions dedicated pins in pin assignment table but I still want to know if I can use any P2 pins for UARTE00. For example, is it possible to use P2.06 to P2.09 for UART with flow control? I understand UART is not mentioned under description and dedicated function of P2.06 but I wanted to know if I can use it by configuration of certain registers.

[Edvin]

Archiet said:

Is there any chance to use P2.06 on UARTE00?

That doesn't seem to work.

I will update you when I know more about the baudrate issue.

BR,

Edvin

[Edvin]

The baudrate issue is fixed, and the fix will be included in future versions of NCS.

Best regards,

Edvin

[Archiet]

Nice!

May I know when will the next NCS be available?

[Edvin]

I don't know. If you want roadmap details, you should contact our Regional Sales Manager (RSM) for your area. If you don't have their contact details, please send me a DM here on DevZone, and link to this ticket. 

Best regards,

Edvin

[pauleffect]

Would you kindly share the fix? I'm guessing that, under the hood, before calling the following function,

nrf_uarte_baudrate_set(get_uarte_instance(dev), nrf_baudrate);

the correct baud rate must be calculated, while taking into account the clock source of the peripheral.

In zephyr's repo, if the peripheral is clocked higher than 16Mhz, the below macro is used to calculate a "custom" baud rate:

#define UARTE_GET_CUSTOM_BAUDRATE(f_pclk, baudrate) ((BIT(20) / (f_pclk / baudrate)) << 12)

Which I think is ok, because for an f_pclk of 16M and a baudrate of 1M, it produces a reg value of exactly 0x10000000 (as referenced by the docs to be 1Mbaud for a 16Mhz clock).