9160DK: need HWFC between 9160 and 52840?

[bluebeam]

Hi,

I'm using the NRF9160DK board. I'd like to connect the UART port from 9160 to the 52840. The 9160 is running SLM firmware. The 52840 is running my code.

My question is about the uart hardware flow control. I assume it's still needed? I remember when I use 52832 in the past it's necessary to have HWFC. Is that still true?

When I enable HWFC on both sides, it seems working ok. When I send 'AT' from 52840 I got 'OK' back from 9160. But when I look at the actual lines, I noticed that nRF52 RTS (nRF91 CTS) is always low. Is that normal? I do have a BLE connection while doing these tests. I expect to see it toggling sometime. I do see the other line (NRF52CTS-NRF91RTS) toggles based on when I send 'AT' from NRF52 to NRF91.

I attached the configuration files for both the 52840 and 9160.

9160.prj.conf52840.prj.conf3835.nrf9160dk_nrf52840.overlay4405.nrf9160dk_nrf9160ns.overlay

[Albrecht Markus Schellenberger]

Hello,

My question is about the uart hardware flow control. I assume it's still needed? I remember when I use 52832 in the past it's necessary to have HWFC. Is that still true?

Unless you do not want to use the Lower power UART driver, HWFC is not necessary. It is a safety mechanism for slow and fast devices to communicate with each other, which shouldn’t matter to much between a nRF9160 and nRF52840.

When I enable HWFC on both sides, it seems working ok. When I send 'AT' from 52840 I got 'OK' back from 9160. But when I look at the actual lines, I noticed that nRF52 RTS (nRF91 CTS) is always low. Is that normal? I do have a BLE connection while doing these tests. I expect to see it toggling sometime. I do see the other line (NRF52CTS-NRF91RTS) toggles based on when I send 'AT' from NRF52 to NRF91.

If the UART driver isn’t actively configured to use flow control, the lines will not toggle. Have you done this in your application?

Regards,

Markus

[bluebeam]

I remember when I use NRF5 SDK and 52832, it's required to have HWFC because the soft device blocks everything during radio activities. Is it not a general concern any more?

Eventually project will go into power optimization stage where everything needs to be low power. So I'd better to make sure my HWFC works properly. I attached digital analyzer tracing. As you can see the RTS from nRF52 is not toggling.

In my code on 52840, I simply hard coded the UART configuraiton and called the uart_configure() function. Is that correct?

  uart1_cfg.baudrate = 115200;

  uart1_cfg.data_bits = UART_CFG_DATA_BITS_8;

  uart1_cfg.parity = UART_CFG_PARITY_NONE;

  uart1_cfg.stop_bits = UART_CFG_STOP_BITS_1;

  uart1_cfg.flow_ctrl = UART_CFG_FLOW_CTRL_RTS_CTS;//UART_CFG_FLOW_CTRL_NONE;//

  CHKERR(uart_configure(uart_dev, &uart1_cfg));

I also have some configurations in the prj,conf and the hardware overlay file. (attached in my first post). Could you take a look to see if they are correct or I missed anything? Thanks!

[Albrecht Markus Schellenberger]

bluebeam said:

I attached digital analyzer tracing. As you can see the RTS from nRF52 is not toggling.

Thanks a lot for your detailed feedback.

bluebeam said:

In my code on 52840, I simply hard coded the UART configuraiton and called the uart_configure() function. Is that correct?

In NCS, the device configuration normally is done via the devicetree, but hardcoding should work fine as well. And according to the digital analyser, it surely does :-) So my assumption is that something is not completely correct on the nRF91 side.

bluebeam said:

I also have some configurations in the prj,conf and the hardware overlay file. (attached in my first post). Could you take a look to see if they are correct or I missed anything? Thanks!

Everything looks good in my opinion. I have double-checked the nRF91_IF and nRF52_IF in the PCB layout as well, and the UART connection between both devices appears to be correct. The only thing that I have noticed is that the Serial LTE modem application uses the CTS pin (19), as sck-pin for the SPI3 peripheral, which is enabled by default.

spi3: spi@b000 {
				#address-cells = < 0x1 >;
				#size-cells = < 0x0 >;
				reg = < 0xb000 0x1000 >;
				interrupts = < 0xb 0x1 >;
				status = "okay";
				label = "SPI_3";
				compatible = "nordic,nrf-spim";
				sck-pin = < 0x13 >;
				mosi-pin = < 0x12 >;
				miso-pin = < 0x11 >;
			};

Normally that shouldn’t interfere as long as the peripheral remains inactive, but could you disable SPI3 and check if that would make any difference?

Regards,

Markus

[bluebeam]

I tried disabling spi3 on the 9160, but it makes no difference. :-(

Why you say it's on the NRF91 side? If it's RTS for NRF52, then should it be on the NRF52 side?

Is it possible that there's never been a conflict so there's no need to raise the line?

[Albrecht Markus Schellenberger]

bluebeam said:

Why you say it's on the NRF91 side? If it's RTS for NRF52, then should it be on the NRF52 side?

My apologies for the confusion. You are right, it is the nRF52 side that doesn’t act as expected.

bluebeam said:

Is it possible that there's never been a conflict so there's no need to raise the line?

This could be an explanation, yes. One way to check if the line is okay could be to configure the UART on the nRF52 side with UART_CFG_FLOW_CTRL_NONE and use uart_line_ctrl to toggle the RTS line manually.

Regards,

Markus