• State Not Answered
  • Replies 14 replies
  • Subscribers 74 subscribers
  • Views 3197 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 306511
Options

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.

Parents
  • 0

    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.

  • 0 in reply to Susheel Nuguru

    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.

  • 0 in reply to 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 zephyr-export
    west build -b nrf5340dk_nrf5340_cpuapp -s main -d main/build -p
    west flash -d main/build

    as long as zephyr environment variables are set. It has come to my attention that cpuapp_ns device tree has a commenting typo error which you should be able to easily fix.

    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.

  • 0 in reply to AstralStorm

    Looking at your configuration in the project that you shared.

    And not knowing the default pull configuration of the peer that is communicating with this, I would suggest you to have both CTS and RTS pull up enabled. I also suggest you to find out the pin pull configuration of the peer device's CTS and RTS that is talking to this uart module.

  • 0 in reply to Susheel Nuguru

    I'm a bit confused about this statement, since pincontrol for uart0 is the following by default
    (from zephyr\boards\arm\nrf5340dk_nrf5340\nrf5340_cpuapp_common-pinctrl.dtsi)
    thus enables the pull-up on RX and CTS, and I'm using VCOM to talk to a PC via USB.

        uart0_default: uart0_default {
            group1 {
                psels = <NRF_PSEL(UART_TX, 0, 20)>,
                    <NRF_PSEL(UART_RTS, 0, 19)>;
            };
            group2 {
                psels = <NRF_PSEL(UART_RX, 0, 22)>,
                    <NRF_PSEL(UART_CTS, 0, 21)>;
                bias-pull-up;
            };
        };
  • 0 in reply to 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?

Reply Children
Related
Terms of service