• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 2342 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2540EMK-USB: Basic serial communication with the usb dongle

Eric Abboud99
Prodigy 40 points
Part Number: CC2540EMK-USB
Other Parts Discussed in Thread: CC2540

Hello, 

A customer gave me an existing enclosure containing the BLE dongle and has asked me to develop some drivers to be able to perform a series of simple tasks (request the address of the dongle, make it avialable for connection, determine the name of the device the dongle is connected to as well as the signal strength). I have been able to communicate with the device using BTool but need to make my application in LabVIEW. I attempted to open the connection by opening a Visa serial comm to the appropriate COM port and defined the serial settings to be the same as the ones used in BTool. However, when I try and write to the device and read back a response, my read times out (I've attached the snippet of code that I am using). I know that the dongle is in a state that should allow me to communicate to it since the customer is currently running an executable that communicates with it. 

From looking around on the forum, it seems that the way in which I communicate with it will depend on what firmware is loaded on. In the small amount of documentation, I found that the previous developers flashed the device with a TI demo hex they called "TI_BLE_Dongle v1_0.hex" but I am not sure if this is the actual name of the firmware or just what the name they gave to the file. Is there a way to determine what firmware is flashed on the device using BTool? 

My final question is about the formatting of the string commands that I will eventually send over serial. From BTool I can see the "TX" for the HCI Reset is "01 03 0c 00". If I were to send the command over serial from my labview code (or any platform for that matter) what exact string would I have to send over? Do I just send that exact string or does it have to be converted from one representation to another? I imagine that sending the incorrectly formatted commands would result in an "invalid" response. Seeing as I have not been able to get any response at all from the board means that I have no way of knowing if I've sent out the correct format or not.

Thank you in advance for the help,

Eric

  • 0
    TI__Guru 56590 points

    Hello Eric,

    I don't recognize the name "TI_BLE_Dongle v1_0.hex". Usually our CC2540 dongles is flashed with a version of the image CC2540_USBdongle_HostTestRelease_All.hex which comes with the BLE-STACK (Support for CC2540/CC2541). The HostTest project contain a BLE network processor implementation with central/peripheral host configuration that expose the Host Controller Interface (HCI). Please refer to the TI BLE Vendor Specific HCI Reference Guide for a list of all the available commands. BTool will configure the device as a Central. I don't know how to identify an image through BTool.

    I am not familiar with the labview VISA implementation. You can perhaps use a script to monitor the COM port transactions to verify how the bytes are sent? There is also a tool called HCTester that can be used to send HCI commands. Please refer to this page and/or search for more info about it on e2e.

    processors.wiki.ti.com/.../LPRF_BLE_HCITester

  • 0 in reply to Eirik V
    Prodigy 40 points

    Hi Eirik, 

    Thank you for the reference to HCI Tester, I have downloaded and I think it will be very helpful in understanding what series of commands I need in order to execute the required steps. 

    Seeing as LabVIEW is a somewhat uncommon platform for communicating to these kinds of platforms, I am first trying to get some kind of communication going over a serial terminal. I have downloaded TeraTerm and Putty but have not had any success. I have formatted the connection as follows: 

    • Baud: 115200
    • Data Bits: 8
    • Stop bit: 1
    • Parity: None
    • Flow Control: None

    I am attempting to send the HCI_Reset command. According to the log from HCI Tester, the outgoing dump is as follows: 

     From my terminal I have tried to send the exact following string "01 03 0c 00" but have seen absolutely no response come back from the device. I am quite confident that the terminal has connected to the device since I am unable to connect to the COM port from the HCI Tester when the terminal is open. I am assuming that I am not sending the command in the correct format but I would have expected to see something come back. Could you please shoe me how to interpret this outgoing dump into a command that I could send over the terminal? Or, if I am missing something in my setup because something has to be changed between using the HCI Tester and a terminal, please let me know. 

    Thanks in advance, 

    Eric

  • 0 in reply to Eric Abboud99
    TI__Guru 56590 points

    Hello Eric,

    The protocol is defined in the TI_BLE_Vendor_Specific_HCI_Guide.pdf found in the installed SDKdocuments folder. Refer to section 8.1  HCI Interface Protocol.

    0x01 - "HCI Command Packet" as described by in Volume 4 Part A.2 of the Core Spec.

    0x030C - "Opcode" (OGF|OCF). Details in Volume 2 Part E Section 5.4.1 of the Core Spec.

    0x00 - Parameter Length byte

    Your setup seems reasonable, but I don't have experience with direct control through UART emulators. I would try to use a UART spy emulator that can observe the traffic on a COM port which is already open in HCITester. On the TI BLE wiki there are some CC254x PC Examples. For example a Python Library for building and parsing vendor-specific HCI packets. You could take a look at it for inspiration. Personally I have never used it and I don't know in which state it is.

    Other tips:

    Our latest development platform (CC264x Launchpad) use a an external virtual COM port so that you can connect a logic analyzer to the RX/TX UART pins to actually verify what is being sent. If you were able to run the HostTestRelease firmware on the CC24540 in debug mode you could catch incoming HCI packets to verify the transactions.