• State Verified Answer
  • Replies 5 replies
  • Subscribers 75 subscribers
  • Views 1664 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296581
Options

Flow control options for nRF52833

bfrottier

Hello,

because of some hardware constraints we had to put our nRF52833 behind an i2c-to-uart bridge (ref SC16IS741A).

Our preliminary tests have showed some potential data loss in the communication from our board to the 52833 using the bridge.

Logs from the bridge driver such as:

sc16is7xx 2-004d: ttySC0: Possible RX FIFO overrun: 64

Or truncated logs generated by the 52833:

instead of:

This led us to investigate the flow control option. Datasheet of the bridge indicates two options:

  1. software with Xon/Xoff characters
  2. hardware

I did some digging in the Connect SDK but only found out hardware flow control support. Is that correct or is there also software flow control available?

The sample we want to use is the Zigbee NCP.

In case only hardware flow control is available, to enable it we would need to set:

CONFIG_ZIGBEE_UART_SUPPORTS_FLOW_CONTROL=y
CONFIG_UART_LINE_CTRL=y

In our prj.conf.

Then configure properly rts-pin and cts-pin in our device tree. Correct?

As we are going to do some DFU over serial the two previously mentioned options will need to also end up in our mcuboot.conf from our child_image, right?

Thanks!

Benjamin

Parents
  • +1

    Hi Benjamin,

    You are right that HW flow control is what is supported, not software flow control.

    You are right about the Kconfig configurations when using Zigbee. Note that CONFIG_ZIGBEE_UART_SUPPORTS_FLOW_CONTROL is just a configuration for the NCP sample, and and if you look at the implementation of the sample (nrf/samples/zigbee/ncp/src/main.c) you can see how it is used. Essentially it reads the pins from the device tree overlay file, and configures the UART accordingly by calls to uart_line_ctrl_set(). The pins come from the device tree (or rather board specific overlay files in the sample), from the UART that is referenced by "zigbee_uart", which for the nRF52833 DK for instance, maps to uart1.

    As the above configuration is only for the Zigbee sample, you can ignore it when it comes to what is used in the bootloader. That will typically use what is in the DeviceTree directly, so you would just need to ensure that you have control set for the UART instance, by having something like this in an overlay file for instance:

    &uart1 {
	status = "okay";
	hw-flow-control;
};

    Einar

Reply
  • +1

    Hi Benjamin,

    You are right that HW flow control is what is supported, not software flow control.

    You are right about the Kconfig configurations when using Zigbee. Note that CONFIG_ZIGBEE_UART_SUPPORTS_FLOW_CONTROL is just a configuration for the NCP sample, and and if you look at the implementation of the sample (nrf/samples/zigbee/ncp/src/main.c) you can see how it is used. Essentially it reads the pins from the device tree overlay file, and configures the UART accordingly by calls to uart_line_ctrl_set(). The pins come from the device tree (or rather board specific overlay files in the sample), from the UART that is referenced by "zigbee_uart", which for the nRF52833 DK for instance, maps to uart1.

    As the above configuration is only for the Zigbee sample, you can ignore it when it comes to what is used in the bootloader. That will typically use what is in the DeviceTree directly, so you would just need to ensure that you have control set for the UART instance, by having something like this in an overlay file for instance:

    &uart1 {
	status = "okay";
	hw-flow-control;
};

    Einar

Children
Related
Terms of service