Zephyr UART on nRF5340 hardware flow control tx breaks

[AstralStorm]

Hello,

I seem to be having a problem with nrf5340 UART on VCOM0 with hardware flow control enabled not being able to transfer anything.
The actual code writing is Zephyr modem command handler, and it happens in both async and interrupt modes, picking a different timer or disabling hw async counter does not help either.
The lockup (waiting on flow control I think) happens on first send.
HWFC disabled sends correctly, receives most of the things, but due to lack of flow control it loses data on receive, so I cannot use it.

UART using uart_get_config definitely prints right baud rate, flow control enabled, 8-bit data, no parity.
uart0 config is the default, except the "CTS pin disable" from the board overlay is commented out.
This is built in non-secure mode, but there's the same issue with secure mode.

The Windows terminal apps I've tried were TeraTerm with RTS/CTS and RealTerm with RTS/CTS and DTR pin set.
Interestingly enough (but unrelated to the issue) nRF9160 SLM works fine in the same setup.

I'll provide a reduced testcase code soon.

[Susheel Nuguru]

Hi Radoslaw,

Sorry for delays, Maria is not feeling well and I will try to assist you.

The lockup (waiting on flow control I think) happens on first send.
HWFC disabled sends correctly, receives most of the things, but due to lack of flow control it loses data on receive, so I cannot use it.

I thought that this is a nRF53 case but looking at the sources this looks like nRF9160. 

When you are able to send when the flow control is disabled, then rest of the code on your device is functioning correctly regarding UART configuration. As soon as you enable the flow control, you are not able to send means that the CTS pin configured in your UART configuration is never getting a green light. This could be because of wrong Pull configuration of CTS. Can you check the CTS pull configuration you are using? I tried to compile your project but it looks like it needs to be in a specific path. I want to see your device tree settings for uart and its pins pull configuration.

[AstralStorm]

The project should not particularly require a path, you might need to remove the .vscode directory if you're using visual studio for the import. That bit could have a hardcoded path. Otherwise, all the paths are relative in CMake files.
Import to nRF Connect SDK in Visual Studio code with "main" as the project should build fine either as nrf5340dk_nrf5340_cpuapp or cpuapp_ns board, or just running from top dir:
west update
west build -b nrf5340dk_nrf5340_cpuapp_ns -s main -d main/build
west flash -d main/build

as long as zephyr environment variables are set.

nRF9160 side works when interacted with the terminal from the PC side, which is why it's not an issue with that. (It uses the default settings from SLM application.) The nRF53 side does not send to PC via VCOM.
RTS/CTS settings for pullup are the default.

[AstralStorm]

Interestingly enough going via direct pins (and correctly configured UART1) mostly works - every third command is not sent, so the main issue is somehow limited to VCOM. Could dynamic HWFC be the cause?

[Susheel Nuguru]

Can you try not using dynamic flow control and also make sure that the pins initial state for CTS and RTS are as expected before the transaction starts on the pins.
Seems like something is off with initial state of the hwfc pins.

[AstralStorm]

How can I turn off dynamic flow control for the VCOM? Seems not possible.

Other than that, RealTerm opens the port with RTS set and DTR set, I can change either to Clear, otherwise responds as expected (at least as expected by nRF9160).
Should it be DTR set and RTS clear?

[Susheel Nuguru]

We have noted that HWFC have some issues with some JLink versions. Can you please check if you have the latest JLink drivers?

After you install the latest JLink, you need to open Segger J-Link configurator and update the firmware on the nRF DK.

[AstralStorm]

The firmware was already up to date according to J-Link Configurator v7.88a. Version: 2022 Nov 7 16:22.

JLink x64 7.84a to 7.88a update sadly changed nothing either. (The 32-bit one is kept at 7.60a for NCS Programmer compatibility.)

[Susheel Nuguru]

I will have to start an internal investigation for this as I am not able to reproduce this issue. I will have to also see if anyone internally have used this configuration in any other setups.

[Susheel Nuguru]

Radoslaw, Could this be related to this issue? The fix for this is supposed to get into our next NCSv2.4.0