• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 1525 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2564 - changing baudrate on when running on H5 protocol

Ulf Karlsson
Prodigy 140 points

Hi

What is the procedure to change baudrate from 115200 to 230400 kbp when using the H5 protocol?

I do not seem to get it to work using the normal VS command:

http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#HCI_VS_Update_UART_HCI_Baudrate_.280xFF36.29

Should the H5 acknowledge package for the HCI command complete be sent on the intial baudrate or the new?

BR

/Ulf

  • 0
    TI__Mastermind 29361 points
    Hi Ulf,

    The HCI Command Complete will still be on the initial baud rate (115200). Everything after that is the new baud rate.

    Are you using the HCITester tool to conduct these tests? If yes, you will need to make sure the the Com_SetParams command in your initscript has Flow Control set to 5 for three-wire.

    Best regards,
    Vihang
  • 0 in reply to Vihang Parmar
    Prodigy 140 points

    Thankyou for response

    Have some followup questions regarding H5.

    We are running a non TI stack on the CC2564B with H5 and have some issues. It seems that the chips stops responding when there is ACL data. I am trying to gather some logs but before I can get some valid data to show:

    Do you have a best practise help regarding H5 communication? Are there some knows issues with the H5 implementation in the CC2564B that needs workaraound?

    Must the host use the H5 sleep control command? Or is it OK just to let the controller sleep?

    If I gather simultaneus air logs and HCI logs, could you look more into the issues?

    Any help would be grateful.

  • 0 in reply to Ulf Karlsson
    TI__Mastermind 29361 points

    Ulf,

    Can you please share the HCI logs and the air logs? This can help look deeper in this issue.

    Regarding the H5 sleep mode command, you can try disabling the H5 Deep Sleep mode using the HCI_VS_Sleep_Mode_Configuration command so that the host does not have to worry about the device going in sleep. It would be a good test in addition to the logs to debug this issue. 

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Prodigy 140 points
    I tried disabling sleep mode but the issue is still happening, no real difference.
    The issue is intermittent and when it happens the BT chip drops a ACL packet and do not send it to host over UART. The logs shows that the first SDP packet is gone between air and host.
    And it seems also depending on timing - if I enable all my internal logs, thus taking longer time to manage the H5 layer, the issue goes away.

    I have managed to take logs, both internal HCI logs (interpreted from another format so timestamps is not correct), and also air log. But how can I share the logs to you Vihang, I do not see a way to upload?

    Let me know how, so I can send the files.
  • 0 in reply to Ulf Karlsson
    TI__Mastermind 29361 points

    You can use the Use rich Formatting option when replying to the post. After that, you will be able to see Insert file button to upload the log.

  • 0 in reply to Vihang Parmar
    Prodigy 140 points

    Ah, great!

    OK, I attach a zip BT snoop log file for the HCI log (converted from my internal logs) and frontline air sniff with the actual failing connection, the CC2564B is acting as a slave.

    Notice how the air log has the SDP search attribute request, but this packet does not leave the controller.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/0160.H5issue.7z