• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 365 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.

BOOSTXL-CC3135: CC3135 UART porting issues - How to reset device in host initialization

Suhel Mulla
Prodigy 175 points
Part Number: BOOSTXL-CC3135
Other Parts Discussed in Thread: CC3135

Hello,


I am referring the below document -

processors.wiki.ti.com/.../CC3100_UART_Host_Interface

I have few queries regarding CC3135 UART communication :



1. In the host initialization sequence diagram, how can I perform the 'reset device' action

(shown in dotted red colored line)? It has to be given as a software command or by hardware pin?



2. Is there any UART prefined command response sequence by which I can just check the is UART working or not?



Regards,

Suhel.

  • 0
    TI__Mastermind 29085 points

    Hi Suhel,

    1. The "reset device" line is not a specific action that needs to be taken by the host. That is what is effectively happening when the sl_DeviceDisable() then sl_DeviceEnable() functions run. It is performing a device reset. The red line indicates the start of the reset sequence.

    2. You could try to compare to something like this which is an example of what the CC3135 response would look like to successfully being started/initialized:

    BA DC CD AB 08 00 14 00 24 00 04 06 00 00 00 00 11 11 11 11 00 00 10 31 00 00 00 00

    Here you can see the first 4 bytes are the sync word. Next is the opcode and length (00 08 is SL_OPCODE_DEVICE_INITCOMPLETE as seen in protocol.h file of driver) 00 14 indicates 20 byte length payload follows. Start by checking that these look correct if you are examining the data placed on the UART lines.

    The protocol is described at a high level in this wiki under "Host communication protcol and flows": https://processors.wiki.ti.com/index.php/CC3100_Host_Interface#:~:text=The%20SimpleLink%20CC3100%20is%20a,driver%20and%20simple%20APIs%20set.

    Best Regards,

    Ben M

  • 0 in reply to Benjamin Moore
    Prodigy 175 points

    Hi Benjamin,

    Your above reply was really helpful.

    The last thing I needed is a small command-response sequence.

    The response you mentioned in your earlier reply

    "BA DC CD AB 08 00 14 00 24 00 04 06 00 00 00 00 11 11 11 11 00 00 10 31 00 00 00 00"

    comes automatically after  nHIb pin is asserted. For this, I don't have to send any command from host (NXP i.MXRT 1052) to the device(TI CC3135).

    Can suggest any such sequence to prove the UART drivers in host are working properly without touching upper layers?

  • 0 in reply to Suhel Mulla
    TI__Intellectual 2345 points

    Hey Suhel,

    After receiving the initialization sequence from your CC3135 you could send the following byte data from your host:

    "FF EE DD BB 21 43 34 12 86 8C 04 00 10 00 01 00"

    The expected response to the above command is:

    "BA DC CD AB 86 0C 0C 00 23 00 04 06 00 00 00 00 00 00 11 11"

    In this example, the byte data sent from your host corresponds to the following command which sets the connection policy to Auto-Connect:

    sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION, SL_WLAN_CONNECTION_POLICY(1,0,0,0), NULL, 0)

    In the response again you're looking for the 4 byte sync word "AB CD DC BA", followed by the opcode "0C 86", payload length "00 0C", and finally the payload data. In this case the opcode corresponds to SL_OPCODE_WLAN_POLICYSETRESPONSE and the length indicates a 12 byte payload.

    Regards,

    Paul

  • 0 in reply to Paul Parrot
    Prodigy 175 points

    Hi Paul,

    Thank you for the reply.

    I have performed the things as per you said earlier.

    I have received below CC3135 response on both Docklight as well as on NXP 1052 host processor receive buffer.

    1. Received initialization sequence from CC3135 after reset pin is asserted :

    "BA DC CD AB 08 00 14 00 24 00 04 06 00 00 00 00 33 33 33 33 00 00 10 31 00 00 00 00

     BA DC CD AB 25 18 14 00 24 00 04 06 00 00 00 00 01 2D 7B 0A 01 2D 7B 0A 00 00 00 00"

    2. Command sent to CC3135 after receiving initialization sequence :

    "FF EE DD BB 21 43 34 12 86 8C 04 00 10 00 01 00"

    3. Response received from CC3135 to the above command:

    "BA DC CD AB 86 0C 0C 00 23 00 04 06 00 00 00 00 00 00 7B 0A "

    These responses are different from the responses you have mentioned. 

    Are these the correct responses from CC3135? 

  • 0 in reply to Suhel Mulla
    TI__Intellectual 2345 points

    Hey Suhel,

    Although the response payload you received is not exactly the same, the response opcode is correct which implies the NWP was able to read the command and send the correct corresponding response.

    Here's a breakdown of what we generally look for in the communication (note data is sent with little endianess):

    Host -> CC3135: "FF EE DD BB 21 43 34 12 86 8C 04 00 10 00 01 00"

    "12 34 43 21 BB DD EE FF" - Host to device long sync word

    "8C 86" - Wlan policy set command op code

    "00 04" - Length of payload (4 bytes)

    CC3135 -> Host: "BA DC CD AB 86 0C 0C 00 23 00 04 06 00 00 00 00 00 00 7B 0A"

    "AB CD DC BA" - Device to host sync word

    "0C 86" - Wlan policy set response op code

    "00 0C" - Length of payload (12 bytes)

    Here we can see the device correctly replied to the policy set command with a policy set response. This means the device was successfully able to read the UART line, parse the command and reply accordingly. The actual data in the payload can vary depending on what mode your device is in and what settings it has.

    Regards,

    Paul

  • 0 in reply to Paul Parrot
    Prodigy 175 points

    That sounds good.

    Thank you for the support...