Connect a Laptop with Windows to Peripheral UART example

Sure, my question is very stupid, but after one day I found nothing to explain the principle of the situation, I decided to ask.

I have a laptop with built-in Bluetooth 5.2 and Windows 11. It runs a terminal testing program.

I have nRF5340 DK with the example Peripheral UART installed (nRF Connect SDK1.8.0). The board works normally, I tested it with a phone with Android and nRF Connect for Mobile. Everything is working fine. The board is connected to a desktop computer on which a terminal program is running and connected to COM port ( not USB).

Windows (laptop), sees the board. After pressing adding device (on Win), the LED on the board (connected) lights up for 1 second, Windows thinks about 5 seconds, and says try again. I imagine that it will connect to the board, and a window will appear to install a serial port to which I can connect through the terminal program. No PIN display window appears. I tried to quickly press button 1, possibly to confirm, nothing. I can transmit data over the phone without the board being BONDED. Let me just say that I've been doing Nordic for 6 months, and I've learned some things. But here I can't even imagine what should happen. Google didn't help either. Does anything else need to be installed on the board?

In the final version, it should be a remote device to which with any laptop with Bluetooth 5.2, to be able to connect and through a terminal program to exchange data via serial port.

  • Hi

    It might be worth looking into the HID profile. It won't give you a direct connection to a serial console, but you can connect directly to the computer and provide various services. For starters the HIDS mouse or HIDS keyboard sample projects might be worth looking at. Or do you specifically need the serial console?

    If you share some information on what the end goal of your application is, that might help us find out what service would be best to use to communicate with the computer as you wish.

    Best regards,

    Simon

  • This idea with HID is good, but for some next stage eventually. It cannot be used at the moment.

    The Dongle idea also has bread in it, but I don't understand something here. I will think about something on the topic in the future. From a consumer point of view, this will be a board with a Nordic chip that has a USB port that is connected to the USB port on the board. It doesn't matter who the manufacturer is. And nRF52840 Dongle happens, or something like that (I don't see the point in putting a powerful processor for a simple USB converter > Bluetooth / Virtual COM for Windows). Why the two examples are not compatible with it (central/peripheral uart). It is clear to me that there is no J-Link on the board, and the development environment (VSC/SEGGER) cannot recognize it (and here there is one but), but there is a nRF Programmer (he recognizes it). Yes, I know, bootloader 1, bootloader 2, etc. Even I did not understand what was happening. Why you can't compile and program with it. I think this is the main application of this board, apart from the sniffer. Simply put on a computer / desktop for example / to provide LBE for tests and experiments with other LBE boards. If necessary, make two special examples of this type of board, which can be programmed only through the programmer.

    On nRF5340DK there is some confusion with com ports. It is not clear how they are counted, and from how much they start, from 0 or from 1. There is some other counting in the documentation. The software usually uses Uart0, which if the first of the possible and should be on P1.00 / 1.01. But in reality, the data that come out through the USB port(J-Link) appear on P0.20 / 0.22 (Uart2 from PCA10095_Schematic_And_PCB.pdf). If someone makes a board that plugs into the kit, will be quite unpleasantly surprised without checking all the signals where they are output.

    Out of pure curiosity, I decided to compile for the USB port, which is directly to the SOC. After 6 hours of fighting and experimenting with punctuation I gave up, there is some mistake somewhere. (\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart)

    VSC:

    Configuration -> prj_cdc.conf

    Extra CMake arguments -> -DDTC_OVERLAY_FILE="usb.overlay"

    The file is attached.

    I wondered what I would see on the computer after plugging in the cable.

     

    Otherwise, at the moment the situation is as follows, I wrote it in my other topic. There is service software that connects through a serial port to our electronics. The software is very complex and large, probably generating 400-500 different commands through the serial port. It is installed on a laptop. We are currently working with USB> RS485 converter. My colleagues travel all over the country and work at different sites. He goes to the place, takes off the equipment, connects the USB cable to the machine and works. Usually 10-20 meters from the machine. This thing can happen several times a day. Currently, a 4-port hub is glued to each laptop. When one port breaks down mechanically, it goes to the other. So, after about 6 months, the hub changes because all its ports are broken (the cable itself is a separate thing).

    Everything is set up in real time, the setting is done while the machine is running, this is how our electronics are made. The commands are up to 40 bytes long (that's the size of the buffers). Usually, one command is 2-3 ms long. After about 100-150 microseconds, the other board starts to respond. That is, this is the time between the last byte of the command and the first byte of the response. The interval between each two commands is 3 ms. Some commands have no response.  Over time, the information that is transmitted increases, and now the RS-485 is slow. I expected to speed up at least a little with Bluetooth. I saw that the minimum times for Bluetooth are 7.5 ms in one direction. And to remove the mechanical connection to the USB.

    This is about the connection between the laptop and the machine.

    It is now planned to offer wireless remote control to customers to control the machine. WIFI doesn't work here because it consumes a lot of electricity. The connection must be encrypted, separately inside there is a second encryption in the packets themselves. The PIN code must be fixed and saved in advance, not visible anywhere (but programmed by my colleague on site at the client.). Separately, after an internal command check, the connection may be disconnected, if the device is not recognized.

    The commands run constantly, they are looped, the times inside the machine are the same.

    A second processor will receive all the internal data, extract the necessary data, and transmit it via Bluetooth to the remote control. About 1-1.5k bytes in the worst case, 5-10 times per second. This is necessary for everything to be smooth. For example, an operator to move the joystick and see the movements in the machine, at the same time there must be feedback/status with indications of what is happening, among other things.

    The colleague with the laptop must connect with the laptop, both to the machine and the remote and set them up in real time. At the moment, all this will work with the RS-485, but it is inconvenient to work. (without remote it works right now.)

    CANBUS is not used because it has many problems and is unusable in our case. But that's another topic.

    And it is planned that everything will go to LAN in the machine. The connection to the laptop will be WIFI or Bluetooth, but the remote-machine remains on Bluetooth for sure. The remote may have an E-Ink display with a second processor.

    But this process is smooth, and we need to keep the maintenance of the old electronics and our customers.

     

    In general, the task is interesting. Slight smile

     

    > Executing task: nRF Connect: Generate config nrf5340dk_nrf5340_cpuapp for SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart <
    
    Building peripheral_uart
    west build --build-dir d:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart\build_1 d:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart --pristine --board nrf5340dk_nrf5340_cpuapp -- -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=On -DNCS_TOOLCHAIN_VERSION:STRING="NONE" -DCONFIG_DEBUG_OPTIMIZATIONS=y -DCONFIG_DEBUG_THREAD_INFO=y -DCONF_FILE:STRING="prj_cdc.conf" -DBOARD_ROOT:STRING="d:/nordic/Stefi" -DDTC_OVERLAY_FILE="usb.overlay"
    
    -- west build: generating a build system
    Including boilerplate (Zephyr base): D:/nordic/SDK/ncs/v1.8.0/zephyr/cmake/app/boilerplate.cmake
    -- Application: D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart
    -- Zephyr version: 2.7.0 (D:/nordic/SDK/ncs/v1.8.0/zephyr), build: v2.7.0-ncs1
    -- Found Python3: D:/nordic/SDK/ncs/v1.8.0/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter 
    -- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
    -- Board: nrf5340dk_nrf5340_cpuapp
    -- Cache files will be written to: D:/nordic/SDK/ncs/v1.8.0/zephyr/.cache
    -- Found dtc: D:/nordic/SDK/ncs/v1.8.0/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
    -- Found toolchain: gnuarmemb (d:/nordic/SDK/ncs/v1.8.0/toolchain/opt)
    -- Found BOARD.dts: D:/nordic/SDK/ncs/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp.dts
    -- Found devicetree overlay: usb.overlay
    -- Generated zephyr.dts: D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/build_1/zephyr/zephyr.dts
    -- Generated devicetree_unfixed.h: D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/build_1/zephyr/include/generated/devicetree_unfixed.h
    -- Generated device_extern.h: D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/build_1/zephyr/include/generated/device_extern.h
    -- Including generated dts.cmake file: D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/build_1/zephyr/dts.cmake
    
    warning: BT_SMP (defined at D:\nordic\SDK\ncs\v1.8.0\zephyr\subsys\bluetooth\host\Kconfig:264, d:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart\build_1\subsys\bluetooth\host\Kconfig:264) has direct dependencies (BT_CONN && BT_HCI_HOST && BT_RPC_STACK) || (BT_CONN && BT_HCI_HOST && BT_HCI && BT) with value n, but is currently being y-selected by the following symbols:
     - BT_NUS_SECURITY_ENABLED (defined at D:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart\Kconfig:23), with value y, direct dependencies y (value: y)
    Parsing D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/Kconfig
    Loaded configuration 'D:/nordic/SDK/ncs/v1.8.0/zephyr/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_defconfig'
    Merged configuration 'D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/prj_cdc.conf'
    Merged configuration 'D:/nordic/SDK/ncs/v1.8.0/nrf/samples/bluetooth/peripheral_uart/build_1/zephyr/misc/generated/extra_kconfig_options.conf'
    
    error: Aborting due to Kconfig warnings
    
    CMake Error at D:\nordic\SDK\ncs\v1.8.0\zephyr\cmake\kconfig.cmake:270 (message):
      command failed with return code: 1
    Call Stack (most recent call first):
      D:\nordic\SDK\ncs\v1.8.0\zephyr\cmake\app\boilerplate.cmake:546 (include)
      D:\nordic\SDK\ncs\v1.8.0\zephyr\share\zephyr-package\cmake\ZephyrConfig.cmake:24 (include)
      D:\nordic\SDK\ncs\v1.8.0\zephyr\share\zephyr-package\cmake\ZephyrConfig.cmake:35 (include_boilerplate)
      d:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart\build_1\CMakeLists.txt:12 (find_package)
    
    
    -- Configuring incomplete, errors occurred!
    FATAL ERROR: command exited with status 1: 'd:\nordic\SDK\ncs\v1.8.0\toolchain\opt\bin\cmake.EXE' '-DWEST_PYTHON=d:\nordic\SDK\ncs\v1.8.0\toolchain\opt\bin\python.exe' '-Bd:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart\build_1' '-Sd:\nordic\SDK\ncs\v1.8.0\nrf\samples\bluetooth\peripheral_uart' -GNinja -DBOARD=nrf5340dk_nrf5340_cpuapp -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=On -DNCS_TOOLCHAIN_VERSION:STRING=NONE -DCONFIG_DEBUG_OPTIMIZATIONS=y -DCONFIG_DEBUG_THREAD_INFO=y -DCONF_FILE:STRING=prj_cdc.conf -DBOARD_ROOT:STRING=d:/nordic/Stefi -DDTC_OVERLAY_FILE=usb.overlay
    The terminal process terminated with exit code: 1.
    
    Terminal will be reused by tasks, press any key to close it.
    

  • Below are my answers to what I picked up as questions from your latest reply. Let me know if I missed some, or if you have further questions. Please note that it's easier to catch them all if you list your specific questions. Also, since this case has moved on from it's initial topic, I would recommend that you create a new DevZone ticket if you have a new issue or require technical support on a different topic.

    nRF5340 DK COM ports: COM ports you're seeing are UART0, UART1, and you can choose from the device manager which ones you want to use in I.E. a terminal. 

    peripheral_uart sample: This sample data received on the RX pin of the UART0 peripheral to the BLE unit. By default, the UART 0 peripheral is gated through the interface MCU to connector J2. To make use of the USB peripheral instead I would suggest checking out the HCI USB sample in Zephyr instead, which is designed to make a USB Bluetooth Dongle from Zephyr.

    Your use case: I understand it as the "remotes" you mention will be nRF5340 devices, correct? And you want to transmit data from these devices over BLE to the computers, which will forward that data to a USB device, correct? Forgive me if I misunderstand anything. The transmission speed (throughput) you mention might be an issue, depending on how many bytes you plan on transmitting at a time. As explained in this blog post, the maximum throughput we're able to achieve with BLE 5 will be ~1400.56 Kbits/s, but that will also depend on the BLE module on the computer's side. If that is sufficient in your case, I don't see any issue this wouldn't be possible. Will the device connected to the computer also be an nRF device? If so you can communicate directly with the nRF instead of having to go through the computer first.

    Encryption should not be an issue either. The nRF53 series use the Bluetooth LE bond module for managing BLE peers and bonds. The computer generally handles this by "choosing" pairing when you connect to a device I believe.

    Best regards,

    Simon

  • So much on this topic here. I accept that you have answered everything that interests me. Thank you for your cooperation.

     

    Regarding the COM port of nRF5340DK. The description is wrong. It's not about the USB port to the computer at all. I connected a logic analyzer to monitor the communication between two boards. Good thing it was the Altium project to find out where to connect my analyzer. Accordingly, the signal passes through other switches, etc. According to the wiring diagram and the declaration in the project, uart0 must be connected on other pins. That's why I wrote that if someone makes a board to plug into the kit and expects the pin signals according to the wiring diagram in your documentation, he will be very badly surprised. Adjust it if you want.

     

    So much here.

  • Hi

    Just to make sure, you're talking about USB connector J2 on the nRF5340 DK, correct? By default, the UART connections should go to the Interface MCU and then to the USB connector from P0.19-P0.22 for one UART,  and P0.10, P0.11, P1.00 and P1.01 for the other. Both of these should be routed to the interface MCU, but are also routed to pin headers that can be "activated" if required. See section 3.2 in the nRF5340 DK user guide for details. If you disagree, can you describe what pins you mean they're going to by default? If there are any mistakes here we of course want to correct it.

    Best regards,

    Simon

Related