nRF52840 TWIS hangs after WRITE_REQ with CONFIG_UART_ASYNC_API enabled; CONSTLAT prevents failure

[Guenther]

I am seeing a reproducible interaction between asynchronous UART support and the TWIS peripheral on an nRF52840 running NCS v3.4.0.

The application uses nrfx TWIS to implement an I2C peripheral interface to another MCU. With CONFIG_UART_ASYNC_API=n, the I2C interface operates reliably.

When CONFIG_UART_ASYNC_API=y is enabled, the first few I2C transactions may complete normally, but eventually a transaction hangs. Instrumentation of the TWIS event handler shows that NRFX_TWIS_EVT_WRITE_REQ is received for the failing transaction, but the expected NRFX_TWIS_EVT_WRITE_DONE event never occurs.

The failure occurs even when the UART instance itself is disabled in devicetree, suggesting that simply enabling the async UART support/configuration is sufficient to expose the problem.

Some additional observations:

• Delaying each MCU request by 10ms causes the 2nd command to fail, implying that timing is significant.
• Running the application under debugger control appears to prevent the failure.
• Keeping main() continuously busy also prevents the failure.
• Setting CONFIG_TICKLESS_KERNEL=n does not prevent the failure.
• Executing NRF_POWER->TASKS_CONSTLAT = 1 during startup prevents the failure and the TWIS interface remains reliable.

These results appear to indicate an interaction with the SoC power/clock state. I do not know whether the root cause is in the UARTE driver, TWIS/nrfx handling, or the associated power/clock management.

I would appreciate guidance on whether this is a known issue and whether enabling the UART asynchronous API could change power/clock handling in a way that affects TWIS/EasyDMA operation.

Thanks

[Pallavi Patil]

Hie,

Sorry for delay in the reply and thanks for your patience. The issue you are facing is an indicators of a power management and clock-state transition race condition involving EasyDMA which is a known problem

Your approach of enabling the UART asynchronous API, enabling CONFIG_UART_ASYNC_API=y directly changes power and clock handling. Because the TWIS (Two-Wire Interface Slave) peripheral relies entirely on EasyDMA to stream data directly to RAM, it requires a stable, running high-frequency clock and uninterrupted readiness to respond to an external master. When the power management subsystem alters clock or power domains right as an I2C transaction is initiated, it triggers a race condition that causes the TWIS state machine to hang.

I hope this helps you.

Regards

Pallavi

[Guenther]

Hi,

Is this a bug that will be fixed or a limitation I have to live with?  Is this "known problem" documented anywhere?  All of my searching for solutions to my issue did not find this which is why I posted here.

What is the power impact of using constant latency mode?

I am porting from a legacy application using the nRF5 SDK which does not use constant latency mode and the TWIS interface functions with no issues.

My application requires fast serial UART streaming support, which lead me to use the Nordic recommended async API.

What do you recommend is my best approach?  Switch to use the interrupt driven UART API?

Thanks,

Guenther