CC3000 not initializing properly

David,

Were you able to solve this problem ??

Currently I am working on porting the drivers to freescale mac71xx and I am also facing the exact same issue.

http://e2e.ti.com/support/low_power_rf/f/851/t/241861.aspx

My control gets struck at the event_handler(), since there is no response from CC3000 after first write.

Any kind of help is appreciated.

Thanks,

Suneel K.V

Sorry, I was not able to get past this problem and had to drop the CC3000 altogether due to time constraints.  We ended up using a WIFI module from another manufacturer that has provided much better support so far.

David,

Our apologies for the delay in answering your question. Let us know if there is anything we can do in the future to make this integration easier for you.

Suneel, 

We will continue addressing your request on the other thread.

Hello,

I have exactly the same problem. Have you found the cause for this issue?

Thanks you.

One more person also having this problem....

Is this some kind of firmware release bug that made it to market on the latest batches of devices? I've seen posts like this in several forums recently and none of them ever have a solution, or even suggestions. 

Give us something!

Alright fellas, I looked through many threads on this forum and LSR's forum and these are the most detailed (and identical) discussions related to this issue:

http://e2e.ti.com/support/low_power_rf/f/851/t/215082.aspx?pi239031349=1

and

http://www.lsr.com/ProductsForum/tabid/164/forumid/8/threadid/1207/scope/posts/Default.aspx

Both of them just abruptly end with "I am driving the spi signals exactly as the documentation describes and it's just not responding!" and the tech support saying "just buy our demo boards!" Also, response times on both forums are RIDICULOUSLY slow. It's up to us to debug this crap, because there is no technical support as far as I'm concerned. It's up to us.

Since everyone that has this problem seems to be trying to port to a different host, I assume the problem is one of the following:

1) The documentation contains errors that the demo-boards are getting around. This could be start-up initialization or the SPI bus control itself. Can anyone get a scope capture of a working demo-board so I don't have to waste time buying one?

2) There is a logic voltage-level difference between the IO. Can anyone verify the exact VCC voltage into the device and the voltages on the SPI,CS,IRQ lines?

3) The modules need patching. From my understanding, there is an IAR project with C code that compiles into a patch programmer that targets a TI chip hooked up to the CC3000. We may need to try porting this patching software to our hosts and implementing a patch. Can anyone verify that a non-patched CC3000 can still respond to the command we are trying to send?

Hi,

I tested with LS Research Module and the evaluation kit : 

1) A capture of SPI show exactly same timing

2) WiFi Module perform a falling edge on its IRQ

I test then my own code with LSR Module in place of CC3000 and .... It works!!!!!

So : CC3000 seems to not be able to be controlled by TI API. 

To conclude, i have just a question : why?

Best regards.

Adrien,

I am using the LS Research TiWi-SL Rev2. You claim you could get it to work? Is there any way you can attach the logic analyzer capture? This is the same module I am using. What is strange is that this module contains a CC3000 and all the documentation points to the same documentation for the TI SimpleLink CC3000.

See: http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_EM

Hi,

I have the same problem than you with the latest CC3000 version wich include all TCP/IP tool.

I have exactly the same logic result than we can see in this thread. 

Except than with the evaluation TiWi-SL kit, the IRQ go to low state again. So, it's ready to send a response. This event occur approximatively 580ms after the first message sent to the module.

 To conclude, the problem come from module hardware or firmware and not from your host firmware/software.

I hope that it can help you and i am searching some response.

Best regards.

I come back again,

have you tried to reload firmware into CC3000?

When i do that, the firmware is not saved.

Your Module are samples or not?

In my case, i have:

1) TiWi-SL Rev2 on eval kit : work fine

2) XCC3000MOD : not preform a falling edge on IRQ after first request.

Best regards.

My modules are the LS Research TiWi-SL Rev2 on the TiWi-SL EM boards (ordered very recently)

I have not tried to reload the firmware on them. But after looking through the Patch Programmer code, it appears as though it sends SPI commands over the same interface with the same format. So I end up with a "chicken before the egg" situation where I can't repatch the firmware because the SPI bus is not communicating correctly.

Unless there is a backwards compatibility issue in which I need to send a DIFFERENT SPI message....but I haven't seen any documentation with detailed message formats (very strange way of business, TI). The best I can do is reverse engineer the driver source code....but I only have one version of that.

Adriene, can you attach a picture of your logic analyzer captures? I'd like to compare.

I m not able to measure again now because my analyzer is used for other kind of measurement.

When i am able to do that, i will attach picture. I try to do that as fast is possible.

Best regards.

Hi,

You mentioned LSR module wakes up and works fine, therefore I can assume you SPI driver code is correct and performing the wakeup sequence.

What I suspect it the firmware that you first tried to download to the XCC3000MOD.

If firmware was not downloaded properly (patches are not burn correctly) it can cause the module not to wake up.

It can happen from several reasons such as stopping the burning process in the middle (it suppose to take around 10 seconds) or burning the patches not in the right order (it must be driver patches first and then firmware patches).

If something happened during the patch burning and the patched that were burned to the EEPROM are not correct, every wakeup the module will try to use these incorrect patches.

In general I would suggest finish porting the SPI driver first and just then (when it is all working) burn the patches with the Patch Programmer.

The first approach is to try to make the module wake up without patch by calling wlan_start(1) instead wlan_start(0).

Calling this API with value 1 instead of 0 will actually cause the module to wake up without patches. Try that and see if the module wakes up.

Also, if you have another XCC3000MOD with no patches burn yet, try it as well.

As a second step, you can download our new patch programmer (v1.10.2) that burn the patches to the module when the module woke up without patches (as opposed to the old patch programmer that burn the patch when the module woke up with patches and could cause an issue if the previous burn wasn't correct).

http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#CC3000.2BMSP430_FRAM

Please try the above and keep me updated.

There is no reason why LSR module would work and XCC3000MOD not. I don't think it is module related.

Jonathan - since you mentioned you didn't burn any firmware yet (good...) and you didn't succeed with the LSR module as well, I think you have a different issue.

I uploaded some scope captures in our other thread, let continue the discussion there.

http://e2e.ti.com/support/low_power_rf/f/851/t/253985.aspx

Yael

Hi,

my investigation show that :

1) If CC3000 dosen't perform falling edge on its IRQ you will never be able to load a new firmware or do a normal start

2) My XCC3000 are.....empty. No bootloader and no firmware (or they aren't functionnal).

The good SPI messages for init can be now found at http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide#CC3000_Init_Operation

Best regards.

Hi Adrian,

You can load new patches (driver and firmware, no boot loader patches needed) if you have an empty EEPROM.

You can use our latest patch programmer utility version 1.10.2 which wake the device without patches by calling wlan_start(1) instead of wlan_start(0).

If you are looking on the CC3000 init operation section on the wiki page you can see that in the first command:  HCI_CMND_SIMPLE_LINK_START you can specify if patches are available from host or not. If not (0 value), CC3000 device will look for them in the EEPROM.

If patches are available from host (value 1), CC3000 will assume there are no patches in the EEPROM and will start the device without patches.

Starting the device without patch is a normal operation, the only affect is that the code fixes implemented in the patches won't apply.

In a case like yours, where the patches in the EEPROM are corrupted or not present, you can start the device without patches (IRQ line will perform falling edge), burn the patches with the patch programmer utility, and then, after the patches are in the EEPROM, run your application with wlan_start(1).

Yael

I saw so many posts regarding the issue like cc3000 does not respond after spi_write,for me also same issue.if anybody knows help me.SPI Write: 01 00 05 00 00 01 00 40 01 00should get response from cc3000 for SPI read isSPI Read: 02 00 00 00 05 04 00 40 01 00spi read is not working as expected,getting only FF's.

Hi,

Can you post a scope capture? What happened after you apply the first write command?

Can you confirm the first SPI command transferred correctly?

Does the IRQ go high? 

Please supply more details.

Yael

During write operation IRQ is going LOW,CS is also LOW but cc3000 does not respond after spi_write.Irq is not going high after spi_write.

am using this code writing over spi

     while(len)
    {
     timeout = SPI_TIMEOUT;
         while (!spi_is_tx_ready(spi))
         {
             if (!timeout--)
             {
                 return ERR_TIMEOUT;
             }
         }
      val = data[i];
         if(len <= 6)
         {
             if(len==6)
             delay_us(50);
             spi_write(spi,val);
             while (spi_writeEndCheck(SPARE_SPI) == 0 ) {  }  
         }
         else
         {
             spi_write(spi,val);
             while (spi_writeEndCheck(SPARE_SPI) == 0 ) {  }  
         }
         i++;
         len--;
     }

for reading

uint8_t read_str[] = {3,0,0,0,0,0,0,0,0,0};

while(len)
    {
        timeout = SPI_TIMEOUT;
        while (!spi_is_tx_ready(spi))
        {
            if (!timeout--) {
                return ERR_TIMEOUT;
            }
        }
         spi_write_single(spi,read_str[read_i++]);
        timeout = SPI_TIMEOUT;
        while (!spi_is_rx_ready(spi))
        {
            if (!timeout--) {
                return ERR_TIMEOUT;
            }
        }
        spi_read_single(spi,&val);
        data[i] = val;
        i++;
        len--;
    }
    return STATUS_OK;

Vishal,

If CC3000 does not raise the IRQ it means the data received from the host was incorrect.

Can you confirm with a scope what is the actual data being transferred?

Yael

Hi,

I have the same problem.

First I developed the porting of the Host Driver for my own microcontroller, and with the LS Research Module (Tiwi-SL) everythings works fine.

Later I made my own board but with the CC3000mod chip and i got the same problem like you 

http://e2e.ti.com/support/low_power_rf/f/851/t/264415.aspx

Did you solve the problem?

Best Regards,

Hi Sergio,

There should not be any difference between these modules.

I have a question for you - did you updated the TI module with the driver and firmware patches?

If so, there might have been something gone bad in this process:

How did you burn the patches? Did you port the patch programmer to your module? What platform did you used as reference?

If the porting wasn't correct and the patches were not burn to the device correctly, the device wont init,

You can check with starting the device with wlan_start(1) instead of wlan_start(0).

This will cause the device to init without patches. So, if they are corrupted it should not interfere.

Yael

Hi,

You said:

<<

If the porting wasn't correct and the patches were not burn to the device correctly, the device wont init,

>>

But if I use the same code with my LS Research Module (TIWI-SL) and everything works fine, so I guess the porting works well

The Only different is the Module CC3000 vs TIWI-SL (Same Code different Harware)

Later I tried to updated the TI modules (2)  with the driver and firmware patches

To burn the patches I use Fram MPS430 Board and I wired my board with FRAM board. Then I execute Driver Patch and Firmware Patch files

With the first of them the proccess works well, Led5+Led8 ON, but with the other none of them is ON

I´m using  CC3000 free samples

Best Regards,

Hi,

So... for my understanding you have one TI module which is working and one not?

Did you try starting the TI module (the non working one) with wlan_start(1)?

Thanks,

Yael

Hi,

I have 3 modules:

1 TIWI-SL ---> Everything works fine

2 CC3000 ---> Doesn´t work

The CC3000 Modules are Mounted in my PCB

If I wired my PCB to the FRAM MSP430 and I run Patch programer and Firmware programer one of the CC3000 module it seems to do the procces fine because the Led5 and Led8 turn ON, but with the other CC3000 none Led turn ON

If I program in my microcontroler an application to create a server or a client everithing woks fine with TIWI-SL but with CC3000 doesn´t work with booth modules

Best Regards,

Hi,

Please try:

1. Start the device with wlan_start(1) with both TI modules. Did you see any change in the init process of the TI modules?

2. When burning the Driver and Firmware patches to the module, you need to confirm each patch is burn completely before moving to the next.

Starting with the Driver patch, this process takes around 10 seconds. It is highly important to wait for completion, otherwise it may not init.

In order to confirm completion I would suggest waiting 10 seconds or even more just to be certain.

Try burning the driver and fw patches again (to both modules) with waiting more then 10 seconds between Driver and firmware. Let me know if this fixed one of the modules.

Yael

Hi,

1. Start the device with wlan_start(1) with both TI modules. Did you see any change in the init process of the TI modules?

The result is the same with booth modules. The process is blocked in the SimpleLinkWaitEvent(); Waiting Simple Link Start

2. When burning the Driver and Firmware patches to the module, you need to confirm each patch is burn completely before moving to the next.

In one CC3000 the process is done OK (Led5+Led8 ON) with Patch Update and later with  Firmware update

In the other when I try to update Patch none Led ON (more than 2 minutes) , so I don´t try update Firmaware

If I run the application (works with TIWI-SL) in booth modules doesn´t works

Best Regards,

Hi Sergio,

Let’s focus on the TI module which is working with the FRAM board.

Since this module is working with the FRAM board you have, there is no reason why this module should not work with your board.

I suspect that maybe wiring is the cause of this issue since the FRAM has TI connector which is the same connector for LSR and TI modules.

If you wire the module manually to your board, the output pins in LSR and TI modules are different.

Can you please specify both of the output pins you wired from these modules? 

Yael

Hi,

With the CC3000 module which is working with FRAM board:

I connect my PCB-CC3000 module to my PCB-Microcontroler with a connector  [FAILS], and I connect my PCB-CC3000 module to FRAM with wires MOSI, MISO, CLK, CS, IRQ, POWER_ON, VDD, GND

When I use TIWI-SL I connect the same lines with wires to my PCB-Microcontroller´s connector [OK]

Best Regards,

Hi,

Can you please specify which exact pin numbers did you connect in the TI mode and which in the LSR module?

Accroding to the schmatics:

8284.TI_module.pdf

6087.LSR.pdf

Yael

Hi, 

All pins are connected well, If it were not so the modules would not work, and the TIWI-SL works every time, and CC3000 works with FRAM

PINS=MOSI, MISO, CLK, CS, IRQ, POWER_ON, VDD, GND

To produce my PCB-CC3000 I use http://www.ti.com/lit/ds/symlink/cc3000.pdf:"Figure 9 shows the schematics for the CC3000 to host reference design."

FAIL:

[PCB-CC3000 --- CONNECTOR] - [CONNECTOR --- PCB-Micro]

[ CC3000          PINS   ] - [  PINS        STM32F103]

To Connect TIWI-SL to my PCB-Micro and PCB-CC3000 to FRAM  I connect following this PDF: http://www.lsr.com/downloads/products/330-0086.pdf

OK:

[PCB ------------------] -- WIRES -- [CONNECTOR --- PCB-Micro]

[TiWi-SL EM Board  PINS] ----------- [  PINS        STM32F103]    

OK:  

[PCB-CC3000 --- CONNECTOR] --- WIRES --- [FRAM BOARD]

[ CC3000          PINS   ] ------------- [PINS MSP-EXP430FR5739 Experimenter Board]

Best Regards,

PD: Is it possible that I need some additional component that is not in the schematic? 

Sergio,

I'm sure you connected the modules to the right pins in your board, (otherwise LSR module would not work as you said) but this is not what I asked.

I think, the chosen pins on the TI module were connected incorrectly.

Can you please tell me (and add a picture if possible) of the connected pin numbers in the TI module (Pin Description at page 3)

Yael

Hi Sergio,

I am happy to hear the issue is solved!

Yael

Hi David,

Would you mind sharing what other sources are out there?

Thanks.

Hi,

I am also having similar problem with CC3000 module.

I am trying to communicate with CC3000  module as specified in the below link.

http://processors.wiki.ti.com/index.php/CC3000_Serial_Port_Interface_(SPI)

But the device CC3000 is not putting high on its IRQ pin after writing first host write command from the master.

I am using the CC3000 EM which was interfaced to LPC1769 controller using SPI.

Please suggest any solution regarding the same issue.

Also share any documents relevant to SPI commands of  CC3000 module.

Best Regards,

Vineela.

Hello Vineela,

can you please create s separate thread, because every problem looks a bit different. Perhaps you can post how you setup SPI on LPC1769. Please tell what is working, what is not working. Can you do SPI logic analyzer traces?

There is a non-official document about SPI:

http://www.embeddedadventures.com/datasheets/WRL-3000_hw_v2_doc_v1.pdf

Best regards,

Martin

Hello Sergio Martin,

I saw that you solved problem when communicating your MCU with cc3000 module TI by adding external capacitor on SPI_CLK line to get imedance matching. I also had the same issue, but I don't know what is the value of capacitor?

Can you help me figure out that value? Can I port host driver on cc3000tiwi LS as cc3000 module TI? they are the same driver host?

Thank you