ncs 1.7.0 peripheral_uart example - fault when data burst received over HW UART

[wiseflag23]

Hi,

I'm working with the ncs 1.7.0 peripheral_uart example and have observed faults when I send more than a few bytes at a time to the HW UART.  (receive by HW UART for transmission over BLE link)

This can be reproduced by connecting the peripheral_uart example to another BLE device, such as the central_uart example, connecting a terminal emulator to the dev kit's UART, and sending a burst of bytes from the terminal emulator to the dev kit's UART.  (e.g. a paragraph of text)

I initially found the issue with ncs 1.6.1, so it's not new.  Another developer at my company has reproduced the issue as well, so I don't believe it's a setup issue.

Log from SEGGER debug terminal:

[01:25:36.951,629] [0m<inf> peripheral_uart: Received data from: C0:EE:40:50:17:6B (public)[0m   (when data flow is slow, pages of these received data messages emit without issues)
[01:25:37.041,687] [0m<inf> peripheral_uart: Received data from: C0:EE:40:50:17:6B (public)[0m
[01:25:37.111,511] [1;33m<wrn> peripheral_uart: Not able to allocate UART receive buffer[0m
[01:25:37.111,541] [1;33m<wrn> peripheral_uart: Not able to allocate UART receive buffer[0m
[01:25:37.115,478] [1;33m<wrn> peripheral_uart: Not able to allocate UART receive buffer[0m
[01:25:37.131,652] [0m<inf> peripheral_uart: Received data from: C0:EE:40:50:17:6B (public)[0m
[01:25:37.131,744] [1;33m<wrn> peripheral_uart: Not able to allocate UART send data buffer[0m
[01:27:26.749,694] [1;31m<err> os: ***** BUS FAULT *****[0m
[01:27:26.749,725] [1;31m<err> os: Precise data bus error[0m
[01:27:26.749,725] [1;31m<err> os: BFAR Address: 0xfb00e5[0m
[01:27:26.749,755] [1;31m<err> os: r0/a1: 0x00fb00e5 r1/a2: 0x200027b4 r2/a3: 0x00000003[0m
[01:27:26.749,755] [1;31m<err> os: r3/a4: 0x00000040 r12/ip: 0x00000000 r14/lr: 0x00020eed[0m
[01:27:26.749,755] [1;31m<err> os: xpsr: 0x21000000[0m
[01:27:26.749,786] [1;31m<err> os: Faulting instruction address (r15/pc): 0x00021408[0m
[01:27:26.749,786] [1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0[0m
[01:27:26.749,786] [1;31m<err> os: Current thread: 0x20001540 (unknown)[0m
[01:27:27.895,294] [1;31m<err> fatal_error: Resetting system[0m
*** Booting Zephyr OS build v2.6.99-ncs1 ***

...

Thanks

[Amanda Hsieh]

Hi, 

Try increasing CONFIG_HEAP_MEM_POOL_SIZE in prj.conf and have a look at this post. 

Regards,
Amanda

[wiseflag23]

Hi Amanda,

    Thank you for looking into this for us.

    We tried increasing the heap size and changing all the stack sizes, and it buffered for a while longer, perhaps 30 seconds of data coming on in the HW UART.

    Eventually, it still locked up, perhaps due to exhausting the heap.

    While this is a demo project and it does indicate that heap memory is getting exhausted, for our purposes of testing maximum data flow, it might be better to complain and drop data rather than exhausting heap.  Also, if the project is reconfigured for HW flow control, it didn't seem to matter.  It might be nice if it could utilize the UART HW flow control, if (re) configured for HW flow control in device tree, prior to exhausting memory.

    Thank you again for your attention.

Regards,

Erik

[Amanda Hsieh]

Have a look at this post. 

-Amanda

[wiseflag23]

Thank you for the reference Amanda, appreciated.

We did experimentally enable HW flow control, but the behavior did not change.  The example code may need to be modified to de-assert CTS when memory starts to run low, or some watermark is reached of allocated UART RX buffers, I expect, such that the remote UART side will then hold-off transmit.  

[Amanda Hsieh]

Hi Erik, 

We cannot reproduce this issue on nRF52DK. Please elaborate in more detail to help us reproduce. 

Which DK are you using? Or are you using a custom board? 

Do you modify any config or code? Please let us know any modifications. 

What data size which you try to send? We tried to send even up to 4kb of data and didn't get any fault. 

-Amanda

[wiseflag23]

Hi Amanda,

   I apologize, somehow I missed the email notification on your reply.

   I'm surprised that the issue did not reproduce for you - I reproduce it easily on a Laird DVK-BL654-1.0 board.  My coworker reproduced it on a Laird BL654-0004 USB dongle.

   All I have to do is run the peripheral UART example, connect it to a Bluetooth central partner, and then send a paragraph or so of text data into the HW UART on the Laird DVK dev board.  (So as to transmit over Bluetooth from peripheral to central.)

   Because the peripheral UART example will continue to allocate memory as it receives data over the HW UART, and the BT transmission rate is limited, it should be easy to exhaust memory on a dev board, I would expect, depending upon how much HEAP is available on your dev board.

   As to priority, this issue is not affecting any of our customers to our knowledge at the moment, but we feel it would be best for the demo code to run without taking a fault to demonstrate the product well.

   Does your team get any of the "Not able to allocate UART receive buffer" messages?  4kb is more than I sent.  But perhaps RAM on the dev boards differs?

   Thanks,

-- Erik