• State Verified Answer
  • Replies 3 replies
  • Subscribers 70 subscribers
  • Views 849 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 319922
Options

nRF Connect tutorial stuck: no COM port shown on device, Seeeduino XIAO BLE Sense

cab938

I'm using the Seeduino Xiao BLE Sense device, which has an nRF52840. I've installed the latest nRF Connect Desktop (4.3.0) in Visual Studio, and version 2.5.0 of the SDK. I've got the Xiao BLE Sense plugged into the Xiao Expansion Board harward so that I can use my J-Link EDU to debug. I'm using Ubuntu linux.

I'm (roughly) following the Nordic Semi tutorial, but am stuck on lesson 3: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-3-elements-of-an-nrf-connect-sdk-application/topic/lesson-3-exercises/

Specifically, the tutorial shows the embedded device has a COM port, here's a screenshot:

However, my device does not have a COM port:

The device tree file for the Xiao BLE Sense is small but includes the line:

#include "xiao_ble_common.dtsi"
Clicking through to this file, it looks to me that the console is set:
Checking the Kconfig it also looks like there is console and serial setup done:

Suggestions on how I go about debugging this further?

I can step through my code on the device, so building, flashing, and debugging are all working, I'm just unable to configure this serial console.

Parents
  • +1

    Hello,

    The tutorials are tailored for our Development Kits, and unfortunately, they may not work as "out of the box" on other hardware. 

    The reason the COM port shows up on the DK and not when you use an external debugger is that the On Board debugger that we are using on the DKs sets up the COM port, and translates from UART to COM, so that your terminal can read it.

    I think the easiest way for you to see the log with your current board would be to either use RTT (on the bottom from your first screenshot), and then use:

    CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_BACKEND_RTT=y

    This way it will use the RTT backend of your programmer instead of the UART bridge that is not present. Alternatively, if you have an external UART to USB device, you can connect this to your extension board. (At least if this is the one you are using, it looks like that would be possible. But I have not tested this board myself). 

    The third option would be to use the USB that is present on the nRF itself. Please note that this works only as long as the application is running as intended. If you run into any issues, and your application crashes, then the USB stack will stop as well, and you may not get as much information as you do if you are using the UART or the RTT backend.

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    The tutorials are tailored for our Development Kits, and unfortunately, they may not work as "out of the box" on other hardware. 

    The reason the COM port shows up on the DK and not when you use an external debugger is that the On Board debugger that we are using on the DKs sets up the COM port, and translates from UART to COM, so that your terminal can read it.

    I think the easiest way for you to see the log with your current board would be to either use RTT (on the bottom from your first screenshot), and then use:

    CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_BACKEND_RTT=y

    This way it will use the RTT backend of your programmer instead of the UART bridge that is not present. Alternatively, if you have an external UART to USB device, you can connect this to your extension board. (At least if this is the one you are using, it looks like that would be possible. But I have not tested this board myself). 

    The third option would be to use the USB that is present on the nRF itself. Please note that this works only as long as the application is running as intended. If you run into any issues, and your application crashes, then the USB stack will stop as well, and you may not get as much information as you do if you are using the UART or the RTT backend.

    Best regards,

    Edvin

Children
  • 0 in reply to Edvin

    Thanks Edvin, this is what I figured but being new to the ecosystem I was unsure! I've got it going with RTT.

  • 0 in reply to cab938

    Glad to hear!

    Yes, I can understand that it may be confusing. 

    As mentioned, it is possible to use the peripheral USB (driven by the nRF) to send data as well. If that is something you want to test, I suggest that you look into the sample:

    v2.5.0\zephyr\samples\subsys\usb\cdc_acm (description),

    But if your intention is to follow the developer academy, I believe using the RTT log is far easier. Note that you may need to reconnect the RTT terminal whenever you recompile and flash the device, because recompiling the application may change the location of the RTT buffer, and the RTT terminal doesn't know whether this address has changed.

    Best regards,

    Edvin

Related
Terms of service