• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 51 subscribers
  • Views 1956 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.

Original question:

CC2564: UART Connection

CC2564: UART / HCI Protocol

Henry Lovett
Prodigy 110 points
Part Number: CC2564

Hello, 

I have an STM microcontroller connected to a CC2564 using HW Flow controlled UART. 

I am able to send all of the service pack (v1.6) and can receive HCI Events indicating success back from the CC2564. However, after I have sent these 50 commands, I can only receive one byte back, which is 48(dec), and then never receive another byte. Sending other commands, for example HCI_VS_DRPb_Tester_Packet_TX_RX with arguments to start transmitting, the CC2564 does act on the command and start transmitting at the expected frequency etc. However, no HCI Event is received. This becomes an annoyance when trying to do a recieve test as the BER Meter result is not received. 

I am confident my low level approach is correct, as it is the same code as for loading the service pack. My general process is:

  • Wait for HOST CTS (Device RTS) to be low. 
  • Send HCI Command packet. 
  • Set HOST RTS (Device CTS) to be low. 
  • Receive 4 bytes, and then receive the remaining number of bytes as in the 4th byte of the payload. 
  • Set HOST RTS to high. 

Any help you can give would be very much appreciated. 

Thanks,

Henry 

  • 0
    Prodigy 110 points
    Further to this, I have edited my code to not load the service pack. The commands then function properly and I get command complete events back that say success. However, I cannot get the receive test I am trying to work to give any results.

    Is there anything special I need to do after loading a service pack to make it all work?

    Many thanks,
    Henry
  • 0 in reply to Henry Lovett
    TI__Mastermind 27080 points
    That seems pretty odd, for the controller not to respond. Did, you try putting a scope or logic analyzer (ex : saleae) on the UART connectors to confirm that the controller is not really sending any response?

    The H4 UART protocol wiring and signalling is provided here - (section 6.4.2.1)
    www.ti.com/.../cc2564.pdf

    Thanks
  • 0 in reply to Hari Nagalla
    Prodigy 110 points

    Hello, 

    I've verified on a scope and the CC2564 sends nothing - the 0d48 was a red herring. 

    Interestingly, if power the board, send a command (HCI_VS_DRPb_BER_Meter_Start, in this case as it is implemented in my software), then load the service pack, the CC2564 does then still work afterwards. I'm calling the exact same functions in both in my code. However, doing this, the BER_Meter_Start doesn't seem to work in general. 

    Would doing this affect the CC2564's ability to load the service pack? 

    I'm happy I have the protocol correctly implemented, given I can send and receive commands successfully most of the time. 

    Thanks,

    Henry 

  • 0 in reply to Henry Lovett
    Prodigy 110 points

    Hi, 

    Is there anything else I should try to solve this? I am still having this issue. 

    Many thanks,

    Henry 

  • 0 in reply to Henry Lovett
    TI__Mastermind 27080 points
    Hi Henry,

    Are, you using STM32 custom board? Or STM3240G-EVAL board? H4 protocol i.e with Hardware flow control is the predominantly used protocol between the MCU Host and CC256x device. I suggest, taking FW logs to ensure that the device has properly detected the UART baudrates and flow control signaling. Please, check here for taking FW logs..
    processors.wiki.ti.com/.../CC256x_Logger_User_Guide

    Please take the logger output, since the beginning, i.e after the device reset.. An example capture on my setup with MSP432 is as below.. Also, please let us know the BTS service pack, you are using?


    31 +0:00:00.002 Transport detection: UART detected
    32 +0:00:00.002 first byte recevied 1
    33 +0:00:00.002 Disable FLIGHT MODE - Enable TX calibration
    34 +0:00:00.002 Uart Active Protocol: H4 PROTOCOL
    35 +0:00:00.002 hcic_process_hci_commands: HCI_RESET (Group 3 Opcode 0x3)
    36 +0:00:00.002 lm_lc_gemini_coex_notify_scan_status
    37 +0:00:00.002 HCI_Reset Completed
    38 +0:00:00.002 hcic_get_num_of_host_commands. Total free = 3, Reported to host = 1
    39 +0:00:00.002 HCI Send Event: HCI_COMMAND_COMPLETE_EVT
    40 +0:00:00.002 Calibration started. Vector=0x1, 0x0
    41 +0:00:00.002 PHY FW Version 3.27
    42 +0:00:00.002 random 0x1be6 0x3b80
    43 +0:00:00.002 random 0x5a6d 0x5a75
    44 +0:00:00.002 random 0xa8b4 0x4a00
    45 +0:00:00.002 random 0x1886 0x7564
    46 +0:00:00.002 random 0x16ff 0x36e
    47 +0:00:00.002 lm_lc_generate_rand
    48 +0:00:00.002 lm_lc_generate_rand
    49 +0:00:00.002 synch event FINISH received, module RF_CALIBRATION, msi 0
    50 +0:00:00.002 hcic_process_hci_commands: HCIPP_UPDATE_UART_HCI_BAUDRATE (Group 3f Opcode 0x336)

    Thanks
  • 0 in reply to Hari Nagalla
    Prodigy 110 points

    Hello, 

    Thanks for this. It is a custom STM board and I am using SP1.6. 

    I will try as you have suggested and get the logs out of the device. I'll report back when I have them! 

    Thanks again,

    Henry 

  • 0 in reply to Henry Lovett
    Prodigy 110 points

    Hello, 

    Sorry for the delay. PFA the logs as requested.

    There are four files in the zip: 

    • 1 tx test mode - just initialising the UART on the STM and running a TX start command
    • 2 rx test mode - just initialising the UART on the STM and running the receiver start commands
    • 3 bt 4.1 service pack then tx test mode - loading of service pack v1.6 then trying the tx command (my error case) and then I don't receive anything back
    • 4 bt 4.1 service pack then rx test mode - loading of service pack v1.6 then trying the rx command (my error case) and then I don't receive anything back

    The debug output implies that the CC2564 is sending a response, however, we do not see anything on the actual UART lines on the scope. 

    Have you got any ideas on what is causing this? 

    Many thanks in advance. 

     /cfs-file/__key/communityserver-discussions-components-files/538/8686.CC2564-bluetooth-debug-messages.zip

  • 0 in reply to Henry Lovett
    TI__Mastermind 27080 points
    Hi Henry,

    As, you mentioned the FW logs look fine with the seemingly the status returned to the host.. Let me check the same sequence on MSP432 LP with CC2564 booster pack.. and will get back..

    Thanks
    Hari
  • 0 in reply to Hari Nagalla
    Prodigy 110 points

    Hello,

    Thank you - please let me know if there are any differences!

    It looks like there is a HCILL sleep at the end of the service pack loading. When we remove this final command, our system runs as expected and we can talk to the CC2564 normally.

    Why is this command here? Is it required? Should it be put to sleep here and then woken up again?

    Many thanks,

    Henry

  • 0 in reply to Henry Lovett
    TI__Mastermind 27080 points
    Hi,

    Yes.. It needs to be turned off.. Please see the note at : processors.wiki.ti.com/.../CC256x_Downloads

    NoteNote: The sleep mode should be turned off in the Service Packs (SP) since this configuration is done as part of the the TI’s Bluetooth stack initialization. If using the BHET tool, the sleep mode can be turned off in the SP Configurations Panel. This option disables the "Deep sleep enable" parameter in the HCI_VS_Sleep_Mode_Configurations (0xFD0C) command that is inside the SP.

    Thanks
  • 0 in reply to Hari Nagalla
    Prodigy 110 points
    Thank you for the clarification!
    Much appreciated,
    Henry
  • 0 in reply to Henry Lovett
    TI__Mastermind 27080 points
    I am closing the thread for now.. Please raise a new one for any other issues.

    Thanks