• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 51 subscribers
  • Views 1371 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.

Sending a sync message to a CC2564 Bluetooth via HTERM, how do i get an answer?

Max Wittmann
Prodigy 50 points
Other Parts Discussed in Thread: CC2564, CC2564MODNEM, SEGGER

Hi,


i am trying to get an answer for a Sync Message i send via HTERM to a CC2564MODNEM Bluetooth Controller. Between my PC and the CC2564 i connected a SEGGER j-link EDU and a board with UART. I want to use the UART Three-Wire connection. I checked with an oscilloscope if the signal arrives at the Debug Pin 12 (HCI_RX with 1.8 V). It arrives and it has 1.8 V.


I created the header and sent a 0x01 and 0x7E afterwards as it stands in the Volume 4 HCI Transport specification of Bluetooth in Part D under point 8.4 (packet type 15, unreliable message, payload length 2). The Controller should send back 0x02 and 0x7D, but it doesn't. I use a 115200 baud rate. What do i do wrong? What is the correct header for the Sync Message?


Regards and thanks in forward


Max

  • 0
    TI__Guru* 85400 points
    Hi Max,

    I will check and get back to you.

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 50 points
    Hi Joseph,

    is there anything you discovered to solve my problem?
    I'd be glad to hear from you.

    Thanks in advance

    Max
  • 0 in reply to Max Wittmann
    TI__Guru* 85400 points
    Hi Max,

    Unfortunately, no update until now. I will let you know as soon as I hear from the team.

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    TI__Guru* 85400 points

    Hi Max,

    Please see attached H5 trace dump example which could help understand the H5 negotiation procedure.

    Regards,
    Gigi Joseph.

    H5 Trace Log.txt 
    11:02:17.802 ThreeWire (H5): Synchronizing...
11:02:17.852 Outgoing Dump:
11:02:17.852     0000: c0 00 2f 00 d0 01 7e c0                         ../...~.
11:02:17.856 ThreeWire (H5): Negotiating for...
11:02:17.856                 Flow Control = None
11:02:17.856                 Sliding Window Size = 7
11:02:17.856                 Data Integrity = 1
11:02:17.856 Outgoing Dump:
11:02:17.856     0000: c0 00 2f 00 d0 02 7d c0                         ../...}.
11:02:18.099 Outgoing Dump:
11:02:18.099     0000: c0 00 3f 00 db dc 03 fc 17 c0                   ..?.......
11:02:18.126 ThreeWire (H5): Negotiated:
11:02:18.126                 Flow Control = None
11:02:18.126                 Sliding Window Size = 2
11:02:18.126                 Data Integrity = 1
11:02:18.126 ThreeWire (H5): Active
11:02:18.126 Outgoing Dump:
11:02:18.126     0000: c0 00 2f 00 d0 04 7b c0                         ../...{.

  • 0 in reply to Joseph Gigi
    Prodigy 50 points
    Hi Joseph,

    Thank you for your response! I've tried to understand your header, but i don't get it. Despite the fact of having a nearly complete different header than yours, everytime i calculate the checksum out of your header, i get 0x00 or 0x01 but not 0xC0 like you. Could you please list the steps calculating the checksum for me?

    It also seems the main problem lies elsewhere. Right after transmitting the .h-file of the service pack RTS becomes 'HIGH'. As it should be low after a proper bootup sequence, i cannot communicate with the CC2564B (MODNEM) anymore. What could be the problem behind this? If you like, i can post the complete service pack .h-file.

    Thank you in advance

    Max
  • 0 in reply to Max Wittmann
    TI__Guru* 85400 points
    Hi Max,

    C0 i believe is the SLIP header. Please see: Volume 4, Part D, Section 3 for more details.

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 50 points

    Hi Joseph,


    i meant 0xD0, not 0xC0. I know, that the C0 is the start and end octet for encoding a SLIP message. Of course i studied the Volume 4, Part D, Section 3 (and all other sections). But there is nothing to solve my problem. As a TI Employee, i was hoping you can help me more than like you did after nearly 2 weeks.


    So you send

    C0 00 2F 00 D0 01 7E c0 (all as hex)


    My question:

    With given information of the first 3 octets of the header (without start 0xC0), how do you calculate a checksum of 0xD0?

    My understanding of the description in section 4.7 would give me

    0x00 0x2F 0x00 0x??


    --> "calculated by setting the Packet Header Checksum to a value such that the 2's complement sum modulo 256 of the four octets of the Packet Header including the Packet Header Checksum is 0xFF."


    This would be 0x00 0x2F 0x00 0xFF

    --> 2's complement:


    0xFF 0xD0 0xFF 0x01

    Modulo 256 --> the rest is 1! --> 0x01?

    So the checksum would be 0x01 with my calculation. the complete header would be c0 00 2f 00 01 01 7e c0, what is wrong.

    How do you get 0xD0 instead of 0x01? Please give a litte more detailed information.

    Thanks in advance

    Max

  • 0 in reply to Max Wittmann
    TI__Guru* 85400 points
    Hi Max,

    ***
    This would be 0x00 0x2F 0x00 0xFF
    --> 2's complement:
    0xFF 0xD0 0xFF 0x01
    ***
    Not sure I follow this. Are you using 2's complement or 1's complement here?

    Regards,
    Gigi Joseph.
  • 0 in reply to Joseph Gigi
    Prodigy 50 points

    Hi Joseph,


    the original Hex:

    0x00 0x2F 0x00 0xFF. This would be in  binary:


    0000 0000 0010 1111 0000 0000 1111 1111

    2's complement of this would be:

    1111 1111 1101 0000 1111 1111 0000 0001

    in Hex:

    0xFF 0xD0 0xFF 0x01

    Isn't that right?

    Regards,


    Max