• State Not Answered
  • Replies 20 replies
  • Subscribers 67 subscribers
  • Views 3758 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 284800
Options

Uart: wrong offset after buffer overflow

MaLu

Hi, hello_world_UART_rx_test.zip

I am trying to use the UART on my nRF9160DK board.

In my program I have 2 uarts in use. uart0 is used for printk output and uart1 is used to receive data in async mode.

I have both connected to the vcom ports on the dev kit (the "usb" port) and have 2 instances of tera term open on windows; one for the printk output, one for the chars i want to send.

Now the problem:

when sending single chars, everything is ok, but if I send a sequence of chars, that would overflow the buffer i have given the uart_rx_enable() or the uart_rx_buf_rsp() function ( eg pasting "abcdef" into the "uart1" terminal when there are already a few bytes in the buffer), I get the free and the request buffer events. after that, I get another rx event.

lets say the buffer is pretty full and I send "abcdef". Then "abc" still fits into the first buffer, I get the rx event for 3 bytes of data. everything ok. free event and request buffer event follow, new buffer is given. Then I immediately get the rx event with the new buffer. in the new buffer is "def", and I get offset=0 (which is ok), but len=1 (which is NOT ok) from the evt parameter in the callback function -> I am not getting notified for the 'e' and 'f' !!
When I send a single new char now, it gets placed after the "def", so on an offset of 3, but in the evt parameter it says offset of 1 (because it ignored the 'e' and 'f' before).

I am surely using the functionality wrong. please take a look at the attached FW, because can't figure out what I am doing wrong from documentation alone.

Thank you!

Parents Reply Children
  • 0 in reply to Øyvind

    Hi,

    Thanks for the update. I tried to closely follow the lpuart example but with a regular uart interface, as it was also using an async api.

  • 0 in reply to Øyvind

    Hi,
    hate to be a hassle, but I just wanted to ask, if you had a quick chance to look into this yet. I need this to work for my project at work, so I wanted to get a bit of an update.

    Thanks in advance!

  • 0 in reply to MaLu

    My sincere apologies for not responding to this earlier. I will provide an answer to you by end of today. 

    Sorry for the inconvenience. 

  • 0 in reply to Øyvind 

    *** Booting Zephyr OS build v2.7.99-ncs1  ***
MAIN START!
uart rx buf req
evt len = 2, evt offs = 0, actual data in 0
12

evt len = 14, evt offs = 2, actual data in 2
3456789012345


freeing buffer
uart rx buf req
evt len = 2, evt offs = 0, actual data in 2
12

evt len = 14, evt offs = 2, actual data in 2
3456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256
1

evt len = 15, evt offs = 1, actual data in 256
23456789012345


freeing buffer
uart rx buf req
evt len = 2, evt offs = 0, actual data in 256
12

evt len = 14, evt offs = 2, actual data in 256
3456789012345


freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 0



evt len = 1, evt offs = 1, actual data in 1
1

evt len = 14, evt offs = 2, actual data in 3
23456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 2



evt len = 15, evt offs = 1, actual data in 2
123456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req
evt len = 2, evt offs = 0, actual data in 256

1

evt len = 14, evt offs = 2, actual data in 256
23456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req
evt len = 2, evt offs = 0, actual data in 256

1

evt len = 14, evt offs = 2, actual data in 256
23456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req
evt len = 1, evt offs = 0, actual data in 256



evt len = 15, evt offs = 1, actual data in 256
123456789012345

freeing buffer
uart rx buf req

    There is clearly something going on.

    Looks like the root cause is the function memcpy copies the whole buffer. There is definitely something off.

    memcpy(au8Main_DummyBuf, evt->data.rx.buf, MAIN_UART_BUF_LEN);

    Still trying to look more into the root cause. 

    -Øyvind

  • 0 in reply to Øyvind

    Hi,
    thanks for the feedback so far.
    the memcpy you mentioned is honestly just for the visualization.

    when you debug into the rx event and look at evt->data.rx.buf in memory, you can see, that in the case of the overflow, new bytes are added to a different offset than evt->data.rx.offset reports

    I mainly copied the evt->data.rx.buf to au8Main_DummyBuf to easily watch it in a debugger watch window.

    Were you able to replicate the issue of new chars arriving into evt->data.rx.buf on a different offset as evt->data.rx.offset ? If not I will make a video or something to help replicate the case

Related