Hi there, I faced this issue while I was setting up a test through two UART0 & UART1 ports on NRF5340 chip, using baudrate 1000,000. Here is the setup: UART0 & UART1 & Kconfigs CONFIG_UART_ASYNC_API=y CONFIG_SERIAL=y CONFIG_UART_NRFX=y CONFIG_NRFX_UARTE=y CONFIG_NRFX_UARTE0=y CONFIG_NRFX_UARTE1=y CONFIG_NRFX_TIMER2=y CONFIG_NRFX_TIMER1=y CONFIG_NRFX_TIMER=y CONFIG_NRFX_PPI=y CONFIG_UART_0_NRF_TX_BUFFER_SIZE=100 CONFIG_UART_0_ASYNC=y CONFIG_UART_0_NRF_HW_ASYNC=y CONFIG_UART_0_NRF_HW_ASYNC_TIMER=1 CONFIG_UART_1_NRF_TX_BUFFER_SIZE=100 CONFIG_UART_1_ASYNC=y CONFIG_UART_1_NRF_HW_ASYNC=y CONFIG_UART_1_NRF_HW_ASYNC_TIMER=2 &uart1 { compatible = "nordic,nrf-uarte"; status = "okay"; current-speed = <1000000>; tx-pin = <8>; rx-pin = <9>; rx-pull-up; }; .baudrate = 1000000, .data_bits = UART_CFG_DATA_BITS_8, .flow_ctrl = UART_CFG_FLOW_CTRL_NONE, .parity = UART_CFG_PARITY_NONE, .stop_bits = UART_CFG_STOP_BITS_1 UART BUFFER SIZE = 1024 &uart0 { compatible = "nordic,nrf-uarte"; status = "okay"; current-speed = <1000000>; tx-pin = <29>; rx-pin = <42>; }; .baudrate = 1000000, .data_bits = UART_CFG_DATA_BITS_8, .flow_ctrl = UART_CFG_FLOW_CTRL_NONE, .parity = UART_CFG_PARITY_NONE, .stop_bits = UART_CFG_STOP_BITS_1 UART BUFFER SIZE = 1024 I enabled hw byte counting to support high baudrate interaction. Test Scenario I send dummy message over uart0 port to nrf5340dk board, and it will be re-routed to uart1 port. Then uart1 side will send back respond message to uart0 side. Issue symptom After I keep sending uart messages around 22 times, only uart2 port will be blocked. And it won't be able to interact with nrf5349dk board. From the log, I can see that after 1024 byte rx buffer is filled-up, endrx events are triggered for both uart0 & uart1 interfaces. Since I'm using HW_ASYNC_TIMER mode, rx_timeout in nordic sdk is kept triggering to polling the status of newly read bytes from RXD through DMA. As it deals with the second NRF_UARTE_EVENT_ENDRX for uart0, uart1 asynchorously detects spurious null byte from no where. Further tests Increase RX Buffer could delay the issue timing. -> it's closed related to 1024 byte buffer size boundary. Made use of logic analyzer. Null byte is not observed in the signal tracing. The next good frame 0x12 0x.. 0x.. 0x12 will overwrite the position of null byte (0x00) in the buffer. -> suspect rx_timeout was triggered wrongly and hw timer logs extra byte for the spurious null byte. Might be something wrong with my configuration? Please help advise. thanks

UARTE Spurious Null Byte Received after NRF_UARTE_EVENT_ENDRX (buffer replacement)

Hi there,

I faced this issue while I was setting up a test through two UART0 & UART1 ports on NRF5340 chip, using baudrate 1000,000.

Here is the setup:

UART0 & UART1 & Kconfigs

CONFIG_UART_ASYNC_API=y
CONFIG_SERIAL=y
CONFIG_UART_NRFX=y

CONFIG_NRFX_UARTE=y
CONFIG_NRFX_UARTE0=y
CONFIG_NRFX_UARTE1=y
CONFIG_NRFX_TIMER2=y
CONFIG_NRFX_TIMER1=y
CONFIG_NRFX_TIMER=y
CONFIG_NRFX_PPI=y

CONFIG_UART_0_NRF_TX_BUFFER_SIZE=100
CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC=y
CONFIG_UART_0_NRF_HW_ASYNC_TIMER=1

CONFIG_UART_1_NRF_TX_BUFFER_SIZE=100
CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC=y
CONFIG_UART_1_NRF_HW_ASYNC_TIMER=2

&uart1 {
compatible = "nordic,nrf-uarte";
status = "okay";
current-speed = <1000000>;
tx-pin = <8>;
rx-pin = <9>;
rx-pull-up;
};

.baudrate = 1000000,
.data_bits = UART_CFG_DATA_BITS_8,
.flow_ctrl = UART_CFG_FLOW_CTRL_NONE,
.parity = UART_CFG_PARITY_NONE,
.stop_bits = UART_CFG_STOP_BITS_1

UART BUFFER SIZE = 1024

&uart0 {
compatible = "nordic,nrf-uarte";
status = "okay";
current-speed = <1000000>;
tx-pin = <29>;
rx-pin = <42>;
};

.baudrate = 1000000,
.data_bits = UART_CFG_DATA_BITS_8,
.flow_ctrl = UART_CFG_FLOW_CTRL_NONE,
.parity = UART_CFG_PARITY_NONE,
.stop_bits = UART_CFG_STOP_BITS_1

UART BUFFER SIZE = 1024

I enabled hw byte counting to support high baudrate interaction.

Test Scenario

I send dummy message over uart0 port to nrf5340dk board, and it will be re-routed to uart1 port. Then uart1 side will send back respond message to uart0 side.

Issue symptom

After I keep sending uart messages around 22 times, only uart2 port will be blocked. And it won't be able to interact with nrf5349dk board.

From the log, I can see that after 1024 byte rx buffer is filled-up, endrx events are triggered for both uart0 & uart1 interfaces.

Since I'm using HW_ASYNC_TIMER mode, rx_timeout in nordic sdk is kept triggering to polling the status of newly read bytes from RXD through DMA.

As it deals with the second NRF_UARTE_EVENT_ENDRX for uart0, uart1 asynchorously detects spurious null byte from no where.

Further tests
- Increase RX Buffer could delay the issue timing. -> it's closed related to 1024 byte buffer size boundary.
- Made use of logic analyzer. Null byte is not observed in the signal tracing.
- The next good frame 0x12 0x.. 0x.. 0x12 will overwrite the position of null byte (0x00) in the buffer. -> suspect rx_timeout was triggered wrongly and

hw timer logs extra byte for the spurious null byte.

Might be something wrong with my configuration? Please help advise. thanks

Parents

0 user72692 over 4 years ago

Hello,

I'l take a closer look at this tomorrow/Thursday.

I send dummy message over uart0 port to nrf5340dk board, and it will be re-routed to uart1 port. Then uart1 side will send back respond message to uart0 side.

Could explain this in more details? If you could upload a diagram of how the nRF5340 DK and the nrf5349dk are connected that would be awesome.

Also, do you have a minimal reproducible sample?

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 user72692 over 4 years ago

Hello,

I'l take a closer look at this tomorrow/Thursday.

I send dummy message over uart0 port to nrf5340dk board, and it will be re-routed to uart1 port. Then uart1 side will send back respond message to uart0 side.

Could explain this in more details? If you could upload a diagram of how the nRF5340 DK and the nrf5349dk are connected that would be awesome.

Also, do you have a minimal reproducible sample?

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 user116741 over 4 years ago in reply to user72692

Hi Simon,

thanks for the help. Actually I'm using nrf5340 chip with our own PCB board, not really the DK board. Let me check whether I can provide a simplified sample to work with.

Best Regards,

Nico
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user72692 over 4 years ago in reply to user116741

Marckel said:
Let me check whether I can provide a simplified sample to work with.

Sounds good. I'll be waiting.

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user116741 over 4 years ago in reply to user72692

Hi Simon,

I found the issue root cause. It's due that the uart port was not de-initialized properly. Let me share you more info tmr. Wondering the proper way to deinitialize the uart and assigned ppi subscription events.

Best Regards,

Nico
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user116741 over 4 years ago in reply to user72692

Hi Simon, thanks for the waiting.

As mentioned, the issue is actually related to uarte0 PPI PUBLISH_ENDRX register is not disabled properly. Let me put the diagram below to show you the scenario.

As ENDRX event is triggered, new buffer is requested. Then you will observe a spurious byte in rx_timeout with length == 1.

I guess this is expected behavior from EasyDMA, if EndRx Event Publishing is kept enabled by accident.

What's the point of view from Nordic side?

Thanks.

Cheers,

Nico
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user65515 over 4 years ago in reply to user116741

Disabling a uart "releases" the Rx pin which often allows the Rx pin to float low which effectively generates a Null or Break (Framing Error) condition when re-enabling. This can be avoided by enabling the Rx pin pull-up; note the pull-up applies to the pn and is therefore not ecliped (disabled) by enabling the Uaart(e) peripheral. If the uart(e) init function explicitly disables the pull-up simply re-enable the pull-up after the uart(e) init.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel