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.

CC256x Bluetooth hardware evaluation tool

Other Parts Discussed in Thread: TM4C1294NCPDT, CC2564, MAX3232

Hi ,

 I am trying to use CC256x Bluetooth hardware evaluation tool . But When i am sending the Service pack it says COM port timed out . I am using tiva C TM4C1294NCPDT and trying in transparent mode . when i was running in debug mode i found out that  i am not receiving any   UART Rx interrupt. But at the same time when i am using debug console and sending some data i could see that UART Rx interrupt getting processed. 

Please let me know is there anything more i need to do or my approach is wrong ?

Regards

Sai

  • Hi,

    Please recheck if all the configurations are correct in the transparency code you have written for TM4C1294NCPDT.

  • Hi ,

      I rechecked all the configurations in the transperancy code. It is fine. However at the UART0 RX line of Tiva , i am not able to see any data on the CRO.

      When i send through hyperterminal i can see the data toggling.

      

    Regards

    Sai

  • Hi Sai,

    The COM port timed out, Can be because of the below reason.
    1. The configuration of the PINS is not correct.
    2. Wrong service pack?
    3. Sleep mode not being disabled(Mind that while downloading the SP, using the BHET tool you need to disable sleep).
    4. Module is defective. where you able to run the demos from the bluetopia release V1.1 and it works?

     

     

  • Hi Sai,

    I recommend verifying the first three sections of our testing wiki:

    http://processors.wiki.ti.com/index.php/CC256x_Testing_Guide 

    Regards,

    Miguel

  • I have the same problem,

    I'm currently trying to implement the Transparent UART as described for the MSP430 controller. I use the Stellaris Virtual Serial port offered by my TM4C123G to talk to the Tiva Controller. The controller forwards the data to the CC2564.

    My current problem is the communication between the BHET and the Tiva controller. I choose the Stellaris Virtual Serial Port (COM21 on my machine) in the Port chooser, select a BTS file and press send. On screen the BHET prints out some hex bytes before it stalls on a timeout. The timeout is OK since I haven't implemented the way back from the CC2564 so far. However, I would expect the bytes printed out on screen to arrive on the Tiva Controller. This does not happen. I cross checked the serial communications from COM21 to Tiva using Terminal software and it worked just fine.

    Will the BHET work at all with the Stellaris Virtual Serial Port?

    Regards

    Martin

  • Hi,

    It should work if you are connecting to the correct com port and using the correct baud rate (also try different baud rates).

    Hope your MCU transparent code is correct?. Did you reset your device before download of  the service pack has started to the board?

  • Hi Sundeep,

    maybe I have to clarify my point.

    My problem lies before I even start passing data through to the CC2564. I am not receiving the data that is coming from the PC in the first place. All software is configured to use a baudrate of 115000 and 8N1. The BHET, the Tiva Software and the Terminal Software I use for cross checking.

    I DO receive (the correct) data on the Tiva side when using terminal software to talk via the Stellaris Virtual Serial Port with this configuration. However, I don't receive data when the BHET uses this port. So I think it is safe to assume that my UART driver is not the problem here. It has undergone rigorous automated ECHO testing for over 24 Hours now, without losing or repeating a single byte.

    I assume I should see at least one byte being sent by the BHET to initiate communications.

  • Hi Martin,

    Do you have any news on this?

    Because i have the same problem.

    When I send HCI commands with Realterm, the cc2564 QFN respond properly,

    But when i try to send the service pack to my cc2564 QFN with BHET.

    most of the times i get "com timed out", and sometimes it load half the service pack and then the program gives a "com timed out" .

  • Hi,

    Sorry missed this post. 

    The BHET does not seem to work with the Stellaris Virtual Serial Port. I just tried it on my side and I see the same issue. We are looking in to it.

    Are you also using the Tiva platform?

  • Hi Sundeep,

    No I'm not using Stellaris Virtual Serial Port, I use Ftdi chip wich is a TTL-232R converter.

    It uses also a Virtual Serial port, I also tried a Max232CPE component.

    So i did not need a Virtual Serial port, but I used a real Serial cable.

    But this had exactly the same result as before.

  • Hi,

    I haven't checked it with Stellaris virtual serial port, but changing the COM port number of a prolific USB/Serial converter to a value below 10 finally solved my problems. Data send by BHET is now received by the MCU. I use a MAX3232 to convert the 3V3 to RS232 levels. I had to do this anyway since the actual hardware does not provide a Stellaris virtual serial port :-).

    Regards,

    Martin

  • Hi Martin,

    Thanks you for posting the solution.

  • Hi Sundeep,

    I think I know what is going wrong with on my CC25645 QFN.

    When I send some HCI commands to the device, most of the times it returns a proper event.

    But always the first time it says:"Uart Active Protocol: H4 PROTOCOL".

    I did not connect RTS and CTS so when I upload the service pack with Bluetooth Hardware Evaluation Tool, its waiting on RTS signal.

    My question is, how can I change the protocol to H5.

    Can this be done with an HCI_Command?

    I can not find it in the bluetooth core specifications.

  • Hi,

    There is no HCI command to do this.

    You need to have H5 driver on you host side, to make the CC256x work in H5 Protocol.

  • Hi,

    Please also see some additional inputs I have received internally:

    Please note that the transport protocol (H4 or H5) is automatically detected by the CC256x in the first command. The transport protocol cannot be changed on the fly.

    Note that the BHET tool only supports H4.

    What does you mean by “waiting for RTS signal”? Is RTS held high by the host or the CC256x?
    I hope the RTS is going low on CC256x, But the host is not aware of it, is my understanding correct?