• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 611 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.

CC3000 Device not responding after first 'HCI_CMND_SIMPLE_LINK_START' command

Kandula Suneel
Prodigy 60 points


Hello,

I am currently working on porting CC3000 to freescale mac71xx controller. I am using CC3000 Evaluation Board from LS Research.

I successfully ported all the CC3000 Platform Independent drivers from TI WIKI, and also completed writing the SPI drivers on mac71xx.

Now, I am struck at a point where, the CC3000 device is not responding after the first 'HCI_CMND_SIMPLE_LINK_START' command.

By not responding I mean, there is no Read request from the CC3000 device (i.e IRQ_PIN is not going down).

Below is the code flow that is happening in Platform Independent drivers from TI:

topapp_function() -> wlan_start() (wlan.c) -> SimpleLink_Init_Start() (wlan.c) ->

         successfully completes : hci_command_send(HCI_CMND_SIMPLE_LINK_START, ptr, WLAN_SL_INIT_START_PARAMS_LEN)

         Now control gets struck at: SimpleLinkWaitEvent(HCI_CMND_SIMPLE_LINK_START, 0), since there is no response from CC3000 device.

Please note that, pooling logic is employed for the pin status change check.

Can someone help me with this? not sure which side is the problem.

Please let me know if more information is required.

Thanks,

Suneel K.V

  • 0
    Intellectual 375 points

    Hello Kandula,

    I recommend you to check if your SPI-Write function working properly. You can trace behavior of SPI and GPIO pins using a logic analyzer.

    Yusuf

  • 0
    TI__Intellectual 2500 points

    HI,

    Would you please check the sequence of all SPI lines, and validate they match our documentation?

    You can probe the SPI lines and compare against the write diagrams mentioned on this page: http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide#Master_Write_Transaction

    You will find two snapshots for first host write and generic write operations.

    Regards,

  • 0 in reply to Beatrice Fankem
    Prodigy 60 points

    Beatrice Fankem,

     

    Thanks for the information and link.

    I got access to LogicAnalyzer last week and figured out that the problem was with the CS not being in de-asserted state when Power Enable is taken to High state.

    I came across several other issues and finally got through all the hurdles. Now I successfully ported a webserver with one .xml and .html page that are working fine now.

    However, I have below questions:

    1) Since I have employed polling logic for IRQ pin status. In order to be able to detect the change in state of IRQ pin reliably I am keeping the CS pin asserted until the software is free to read/write the data to/from the CC3000 device. So you see any problems with this kind of implementation ??

    2) I noticed that CC3000 IRQ pin state changes in terms of 20ns, while the average time is in terms of 7 micro seconds. my questions is what scenarios CC3000 does this?? any insight into internal state machine of CC3000?

    3) CC3000 seems to be not transmitting data > 1024 bytes (during webserver implementation) . Although I am pumping the data of > 1024 bytes, my mobile device is not able to receive all the bytes. I have set the MTU to be 1024 bytes in this case.

     

    Thanks,

    Suneel K.V

  • 0 in reply to Kandula Suneel
    TI__Intellectual 2500 points

    Hi Suneel,

    Thank you for the uppdate on the first issue, and letting us know that it is now resolved.

    If you don't mind, could we please close this thread?

    Let's open another thread for the new questions?

    Regards,

    Beatrice

  • 0 in reply to Kandula Suneel
    TI__Intellectual 2500 points

    Suneel,

    With regards to the 3 questions previously asked. 

    1. Change in IRQ state is detected by interrupt and not by polling.

    No other implementation is supported.  Please see MSP430 SPI driver as reference. This wiki page has further details on the protocol description: http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide#Master_Write_Transaction

          2.    IRQ state changes according to data waiting to be written or data is ready to be received (CS assert detection). These transitions are also mentioned int he link above for various states.

         3.    Please check that the application.. You can you capture the logs, to see how much bytes the application sends in one packet.