NCS UART uart_poll_out with nordic,nrf-uart faulty TX, but works nordic,nrf-uarte

Hi folks,

The blocking transmit function uart_poll_out() works as expected with UARTE, but not with UART.

For our project low power is critical. Thats why I need to use UART (~300 uA) instead of UARTE (~1300 uA). Baud is very low, so DMA does not benefit us.

brd_test.overlay file -> uart0 ->  compatible = "nordic,nrf-uart";

Figure. UART - faulty transmission

brd_test.overlay file -> uart0 ->  compatible = "nordic,nrf-uarte";

Figure. UARTE - transmission OK.

I also tried calling uart_irq_tx_ready() inside ISR -without effect.



I took the echo_bot example and modified it. Here are the files that i modified (i removed RX code for cleanness sake):

5852.main.cpp7028.prj.confbrd_test.overlaybrd_test.dtsi

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(echo_bot_2)

target_sources(app PRIVATE src/main.cpp)

Second issue is that calling uart_irq_tx_enable(uart_dev) ends in signal handler. Please test it by adding uart_irq_tx_enable() inside uart_tx(). I hoped to work around the faulty transmission by using interrupt driven api, but I cant even enable the tx interrupt in the first place.

Third issue is being able to disable receiver (only async api has RX enable/disable). Unfortunately I couldn't get the async api it to receive in a stable manner. Thats another rant.
For interrupt driven driver I managed to get the sleep power consumption down 2.7 uA by calling pm_device_action_run() manually (as seen in the code). Are there any caveats doing it?

Parents
  • Hi

    Okay, if it's reproducible on the DK, we'd very much like to reproduce it on our end. Can you provide either a project or .hex file where it's easy to reproduce on a DK?

    Also, discussing this with a colleague, we realized that the stop bit after the first transmission on the UART trace seems to not be a digital signal, but rather a component or the pin going off since the fall on the last byte has this weird curve, so we're expecting that this is either an issue with how the GPIO is handled or with the component the UART is connected to. It's also worth noting that this is the 8th byte (stop byte) after the first transmission and it seems like the transmission is basically ending abruptly. So, is the data before this also jumbled, or does it start out by sending correct data?

    Best regards,

    Simon

Reply
  • Hi

    Okay, if it's reproducible on the DK, we'd very much like to reproduce it on our end. Can you provide either a project or .hex file where it's easy to reproduce on a DK?

    Also, discussing this with a colleague, we realized that the stop bit after the first transmission on the UART trace seems to not be a digital signal, but rather a component or the pin going off since the fall on the last byte has this weird curve, so we're expecting that this is either an issue with how the GPIO is handled or with the component the UART is connected to. It's also worth noting that this is the 8th byte (stop byte) after the first transmission and it seems like the transmission is basically ending abruptly. So, is the data before this also jumbled, or does it start out by sending correct data?

    Best regards,

    Simon

Children
No Data
Related