9160DK: need HWFC between 9160 and 52840?

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

Parents
  • 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

Reply
  • 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

Children
Related