Cannot tell when a host PC has connected to the nRF52832DK

Hello. I'm using the nRF52832DK in a test fixture application. 

I need the embedded system to know when either:

- a PC has connected and disconnected to the main USB connector

- a PC host has opened and closed the serial Port of the nRF52832DK

The interface MCU and nRF52832DK are connected via UART utilizing HWFC. However, no amount of adjusting the code on the nRF52832DK can get these RTS/CTS lines to change state. I have my .dts node designed with hw-flow-control set for uart0. 

When I open the terminal using tio, I have tried different flow control settings as well. 

Are there any code samples that utilize HWFC on the nRF52832DK? I would expect these pin values (RTS/CTS) to change based on if a host is connected, yet everytime I probe them, they're 0V. 

Thanks,

Rob

Parents
  •  , I'm working with  on this.  Per the Nordic documentation it sounds like this is the expected behavior:

    - CTS is left high-Z by the interface MCU when no virtual-serial terminal is connected via a computer

    - The computer software must connect and send a Data Terminal Ready (DTR) signal 

    - The CTS signal is then "driven"  (Assuming this means driven low)  "when the first data is sent or received" (TBD if this means a DTR signal from the computer or actual UART data coming through on the interface MCU's TX.

    - Hardware flow control is continued to be used until a power-on reset or "until a new DTR signal is received and the detection is redone"

    We aren't seeing that behavior.   We're unable to make hardware modifications at this point unfortunately.  We're using the DK within high-volume manufacturing equipment for testing a Nordic-based product.  I'll reach out to our FAE and sales rep in case that helps you/us get more support on this.  

    Thank you

    -Ray

    https://docs.nordicsemi.com/bundle/ug_nrf52832_dk/page/UG/dk/vir_com_port.html

    The UART signals are routed directly to the interface MCU. The UART pins connected to the interface MCU are tri-stated when no terminal is connected to the virtual serial port on the computer. The terminal software must send a Data Terminal Ready (DTR) signal to configure the UART interface MCU pins.

    ...

    Automatic HWFC detection is done by driving Clear to Send (CTS) from the interface MCU and evaluating the state of Request to Send (RTS) when the first data is sent or received. If the state of RTS is high, it is assumed HWFC is not in use. If HWFC is not detected, pins P0.10/P0.21 P0.07 (CTS) and P0.05 (RTS) are free for the nRF application to use.

    After a power-on reset of the interface MCU, all UART lines are tri-stated when no terminal is connected to the virtual serial port. If HWFC has been used and detected, P0.07 (CTS) is driven by the interface MCU until a power-on reset has been performed or until a new DTR signal is received and the detection is redone.

Reply
  •  , I'm working with  on this.  Per the Nordic documentation it sounds like this is the expected behavior:

    - CTS is left high-Z by the interface MCU when no virtual-serial terminal is connected via a computer

    - The computer software must connect and send a Data Terminal Ready (DTR) signal 

    - The CTS signal is then "driven"  (Assuming this means driven low)  "when the first data is sent or received" (TBD if this means a DTR signal from the computer or actual UART data coming through on the interface MCU's TX.

    - Hardware flow control is continued to be used until a power-on reset or "until a new DTR signal is received and the detection is redone"

    We aren't seeing that behavior.   We're unable to make hardware modifications at this point unfortunately.  We're using the DK within high-volume manufacturing equipment for testing a Nordic-based product.  I'll reach out to our FAE and sales rep in case that helps you/us get more support on this.  

    Thank you

    -Ray

    https://docs.nordicsemi.com/bundle/ug_nrf52832_dk/page/UG/dk/vir_com_port.html

    The UART signals are routed directly to the interface MCU. The UART pins connected to the interface MCU are tri-stated when no terminal is connected to the virtual serial port on the computer. The terminal software must send a Data Terminal Ready (DTR) signal to configure the UART interface MCU pins.

    ...

    Automatic HWFC detection is done by driving Clear to Send (CTS) from the interface MCU and evaluating the state of Request to Send (RTS) when the first data is sent or received. If the state of RTS is high, it is assumed HWFC is not in use. If HWFC is not detected, pins P0.10/P0.21 P0.07 (CTS) and P0.05 (RTS) are free for the nRF application to use.

    After a power-on reset of the interface MCU, all UART lines are tri-stated when no terminal is connected to the virtual serial port. If HWFC has been used and detected, P0.07 (CTS) is driven by the interface MCU until a power-on reset has been performed or until a new DTR signal is received and the detection is redone.

Children
  • Raymond said:
    The CTS signal is then "driven"  (Assuming this means driven low) 

    Correct, it uses an internal pullup. 



    Raymond said:
    We aren't seeing that behavior. 

    I have not tested this myself atm but I will look in to this. 


    Raymond said:
    .  I'll reach out to our FAE and sales rep in case that helps you/us get more support on this.  

    Yes, always good to push form more than one angle if you need to get things done quick. 


    What SDK are you using, NCS verison ?

    Regards,
    Jonathan

  • Hey  

    Thank you for confirming these things.  We hadn't had a strong enough pull up override the interface MCU's CTS pulldown.   We're now using a stronger pullup and seeing the expected behavior.  

    However, just as feedback regarding this product,  it's a real pain for us that the CTS line doesn't return to high-z to indicate when the USB-serial connection is closed.  Without that behavior, there's no way for the application MCU to detect when it has a USB-serial connection established.   

    Perhaps this could be an improvement in coming versions of the interface MCU firmware! 

    Thanks again

    -Ray

Related