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.

wlan_start(1) doesn't work

Other Parts Discussed in Thread: MSP430FG4618, MSP-EXP430FR5739, MSP430FR5739, MSP430F5336, MSP430G2553

Hi, 

I was ported the SPI driver to STM32 MCU. Everything is OK. I can configure the network parameters, I can open a TCP client, sending and receiving TCP data and the same thing for the TCP server.

I use the 1.19 firmware version in my CC3000 and the SPI version 7(ported) and the host driver version 13. As I am telling you, every thing it's OK.

My target now, it's to use your patch programer application (PatchProgrammerLM4F232H5QD-4.11.7.13.19  as referece). But when I try to execute the wlan_start(1) it doesn't work. It is blocking permanetly.

I don't why, because as i told you the rest of the things are OK. If I uses  wlan_start(0), it works fine...

I read that in this mode, it can takes you around 10seconds, in my case i was waiting for it around 2 minutes... Any suggestion? It's a little bit strange, isn't it?

I put a piece of my code, just in case you can help my better:


char *sendDriverPatch(unsigned long *Length)
{
*Length = 0;
return NULL;
}

char *sendBootLoaderPatch(unsigned long *Length)
{
*Length = 0;
return NULL;
}

char *sendWLFWPatch(unsigned long *Length)
{
*Length = 0;
return NULL;
}

void CC3000_UsynchCallback(long lEventType, char * data, unsigned char length)
{

}

main(){

/* WLAN On API Implementation */

wlan_init(CC3000_UsynchCallback, sendWLFWPatch, sendDriverPatch, sendBootLoaderPatch, ReadWlanInterruptPin, WlanInterruptEnable, WlanInterruptDisable, WriteWlanPowerEnable);

/* Trigger a WLAN device */

wlan_start(1);

...

}

Thanks and best regards.

Carlos

  • Which compiler you use?
    I had problem with wlan_start() functions in CCS. But, my problem has been in linker,and i am solved problem with changing linker

  • hi!

    I am using ARM-compiler provided by codesourcery tool-chain. Can you tell your exactly error in the linker to take notes about it?

    It's curious because wlan_start with the param set to '0' works well...

  • Cam anybody help me please? I can't see what's the problem... when I try to run the PatchProgrammerLM4F232H5QD-4.11.7.13.19 application, it is blocking in the first wlan_start(1). It's like something is missing, Becasue I can see that the IRQ works but this funcion never returns.

    Has anyone tried the patch programer applications? 

  • I was investigating in this topic. I have two option for the wlan_start() function:

    -----> WLAN_START(0)

    If I execute this function with the parameter set to '0', everything it's OK, I can see in my logic analizer the HCI_CMND_SIMPLE_LINK_START command anwser.
    It works fine, I can open a TCP server and receive data from another TCP client and open a TCP client too.

    -----> WLAN_START(1)

    When I execute this function with the parameter set to '1' according to re-program the cc3000 device I got the following commands and event secuence:


    1- Command HCI_CMND_SIMPLE_LINK_START.
    02 00 FF 00 00 00 00 00 00 00
    01 00 05 00 00 01 00 40 01 01


    2- Event to confirm HCI_CMND_SIMPLE_LINK_START command
    02 00 00 00 07 04 00 10 02 00 01 00
    03 00 00 00 00 00 00 00 00 00 03 00

    3- Command HCI_EVENT_PATCHES_DRV_REQ. Sent from hci_unsol_handle_patch_request() in hci_event_handler
    02 00 FF 00 00 00 00 00 00 00 00 00
    01 00 07 00 00 03 01 02 00 00 00 00


    4- Event to confirm HCI_EVENT_PATCHES_DRV_REQ command

    02 00 00 00 07 04 00 10 02 00 03 00
    03 00 00 00 00 00 00 00 00 00 03 00

    5- Command HCI_EVENT_PATCHES_BOOTLOAD_REQ. Sent from hci_unsol_handle_patch_request() in hci_event_handler.
    02 00 FE 00 00 00 00 00 00 00 00 00
    01 00 07 00 00 03 03 02 00 00 00 00


    6- Event to confirm HCI_EVENT_PATCHES_BOOTLOAD_REQ command. Sent from hci_unsol_handle_patch_request() in hci_event_handler.
    02 00 00 00 07 04 00 10 02 00 02 00
    03 00 00 00 00 00 00 00 00 00 03 00

    7- Command HCI_EVENT_PATCHES_FW_REQ. Sent from hci_unsol_handle_patch_request() in hci_event_handler.
    02 00 FE 00 00 00 00 00 00 00 00 00
    01 00 07 00 00 03 02 02 00 00 00 00

    The next event should be the event to confirm HCI_EVENT_PATCHES_FW_REQ command but it never happends.
    If this event never happends, it's impossible to return of the wlan_start(1) function. So here it's my problem...

    Can you tell me or advice anything about this topic?
    I'm sure that my SPI driver works fine because I can manage the cc3000 when I start the module with wlan_start(0), but... I don't know what it's happening. Even if I try to send the Command HCI_EVENT_PATCHES_FW_REQ in isolation, the event never  happens... 


    Thank you in advance and best regards.

  • Team, can you please reply to this post? It has been more than 10 days without any answer. Thansk, Beatriz.

  • Hi to everybody,

    I am facing exactly the same issue. I've ported the SPI in order to interface the CC3000 with an MSP430FG4618. With wlan_start(0) it behaves correctly, but when I want to update the Driver patch I experience exactly the problem described in this post, i.e. wlan_start(1) does not return and stucks in that point receiving no answer. I am using 1.10.2 Application version, so the correct service pack to download in the CC3000 EEPROM is 1.14 . 

    I hope someone will help us with this issue, I have faced this problem for many days.

    Thank you very much and Best Regards,

    Mario Demaria

  • Hi there,

    we also have exactly the same problem.

    We are stuck since a while.

    Can some one help?

    Greetings

    Leo Reyneri

  • Hello Carlos,

    How are you confirming the messages are being sent correctly? Can you possibly probe the SPI lines and make sure the last command is making it out, and also make sure the command complete response is not making it back? If there is no physical response from the CC3000, can you send the SPI traces of the last command? You may want to try lowering the clock speed or turning off optimizations, to see if there is insufficient delay somewhere.

     

    Thanks,

    Aaron

  • Hi there,

    We are also experiencing the same issue as everyone else. The CC3000's firmware is currently on 1.10, wlan_start(0) works and we are able to send UDP packets. We've ported the driver patch and wlan_start(1) never gets out of SimpleLinkWaitEvent(HCI_CMND_SIMPLE_LINK_START, 0);


    Does anyone have any updates as to what is happening?

  • Hello Aaron,

    I used my logic analizer to check the requests and the answers... So I can confirm you that there's not answer to the last command. In addition, I have tried to send the last command in the first position of these command group to set up the device and the result is the same, there's no answer for that command... I don't think that it is a SPI problem because as i have told you I can manage the whole device... sending and receiving information without a problem... In addition more people has the same problem... Can you help me please?

     

  • Carlos,

    Please provide a trace showing the wlan_start(1) sequence. I would like to see the timing between all of the commands and their replies.

     

    Thanks,

    Aaron

  • Hello Aaron/TI and all with this problem,

    the error seems to be meanwhile almost 6 weeks old and some people have reported the same problem.

    Can TI check on their side if "PatchProgrammerLM4F232H5QD-4.11.7.13.19" is working correctly and create (readable) SPI traces, so others can check at which point they have problems and perhaps are able to solve the problem by themself?

    @All with the problem:

    Is the problem still existing on your side or were you able to solve the problem? If solved, how were you able to solve the problem?

    Is at least one of you (who still has the error) able to create traces (SPI, perhaps TI internal trace over USB <-> SERIAL converter) and give it to TI for further analysis?

    Many thanks,

    Martin

  • Hello,

    The problem persist and now more people have the same problem. I took several traces with my logic analyser. They are attached to this reply.

    They are 7 and they are named by executing order. If you pay attention to the last one, you can see that the last event never happend, then it won't be return of the function where this command was executed.

    Can you help me with this issue?

    Best regards.3580.wlan(1).rar

  • Hello Carlos,

    can you point me to the needed software to open your traces? It seems to be *.law files, in the header "Acute Technology Inc.  LAW 3.01" is mentioned. Is it some software from http://www.acute.com.tw/download.php ?

    Best regards,

    Martin

  • Yes!, this is my logic analyser model, Can your try it? I hope you don't have any more problem with that and sorry for that. If you can't open them, tell me and I'll paste them in a image format.

    Best regards

  • Hello Carlos,

    i was able to open the traces with Logic Analysis 2.7.5.7. I see that each file contains 1 or 2 packets.

    Is the content different to the packets mentioned above (packet 1 is in file 0, packet 2 is in file 1, and so on)?

    Would it be possible for you to make a complete trace in one recording (don't know if this is possible with your logic analyzer), so you can see all packets in one trace and see the time between requests (commands) and possible answers (events). As i understand this is the info Aaron needs.

    The other possibility could be to create a trace of the complete sequence on pin 2 and a trace of a complete sequence on pin 4 of CC3000MOD.

    See

    http://processors.wiki.ti.com/index.php/CC3000_Logger

    for details. Do you have a USB <-> Serial converter based on 1,8V level, as mentioned on the page?

    Best regards,

    Martin

  • I'm sorry but i can't get more frames in a single trace because my analyser doesn't have enoght buffer for that, but as you can see all processes are correct but the event which confirm the  HCI_EVENT_PATCHES_FW_REQ command doesn't happend. 

    I don't have UART debug to get the debbug information. Then I would like that Somebody help me with this topic.

    Can TI staff tell anything more about that?

    Best regards.

  • Hello Carlos et all,

    i am able to reproduce your case with my environment and CC3000MOD.

    Background: I am currently trying to update my firmware of CC3000MOD. I was able to delete my firmware, but not write a new one, so my module is empty. But is reacting in a similar way like your module. See

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

    for details.

    When i send exactly the same sequence of commands like you i get exactly the same answers and no answer on last event. I attach a trace of my logic analyzer which contains the complete sequence. I have send the commands by key presses (no automatic answering), so time is a few seconds between each command. Logic Analyzer is a very old model, DV1-100, software version 6.0.4 or 7.0.2 can be downloaded from http://www.tech-tools.com/d_digiview.htm .After loading the trace press Shift-O to zoom fully out and mark certain positions with the mouse, till you see hex data in last two rows. Press O again to zoom out.

    I also think i have a possible reason why CC3000 behaves in this way:

    You call wlan_start(1) which means start and "Host has patches". The CC3000 requests patches, but you always say: No, i have no patch. Now finally when CC3000 has requested all 3 patches (drv, bootload, fw), what shall it do? You say start with my patches, but then deliver no patches...

    (Ok, perhaps it would be better to say, no, starting not possible, big error happened...).

    Have you tried to deliver the patches? At least for drv and fw the patches for latest release are available here inside the projects (e.g. in TivaC project):

    http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads#Patch_Programmer

    Here:

    C:\ti\PatchProgrammerLM4F232H5QD-4.11.7.13.19\Patch Programmer Source\Source\Patch Programmer\PatchProgrammer.c

    search for wlan_drv_patch and fw_patch

    All of the above is just speculation, here TI is needed to confirm and tell what to do!

    Best regards,

    Martin

  • Hello,

    We have been talking about this issue several day without a valid or util answer. We shouldn't make assumptions... I need help, can somebody of texas instrument company tell me anything else about this problem?

    I do only that TI says if I want to update my cc3000 using a code, but it doesn't work... 

    Best regards.

  • I just created a trace of both debug pins of this situation,where no answer is sent by CC3000.

    Hope it helps TI to give some hints how to solve this problem:

    8816.trace_debug_pins_no_answer.zip

    In trace_no_answer_y.log i see the following sequence again and again:

    09 06 0C 00 09 06 0C 00 09 06 0C 00 09 06 0C 00

    09 06 0C 00 09 06 0C 00 09 06 0C 00 09 06 0C 00

    Does this mean a endless loop or crash of CC3000?

  • Another trace from the internal debug pins, this time i don't see the repeating sequence,

    but reaction on SPI is the same (no answer on last command):

    8037.trace_2_debug_pins_no_answer.zip

  • Hey everyone,

    I just used a TI FRAM board to do the firmware & driver patch updates. Here are the logic traces. I don't have time to cross reference them with what you guys are getting right now, but hopefully this will help you guys. It's an upgrade from v1.10 to v1.19

    2555.cc3000-ti.zip 

  • With which logic analyzer have you recorded it? Can you send a link to viewer software?

  • I recorded it with the saleae logic http://www.saleae.com/logic16

  • Hi Jia,

    i just had a look at your driver-patch trace:

    0ms -> SW_EN=1

    63420us -> 01 00 05 00 00 01 00 40 01 01 (wlan_start)

    70940us <- 02 00 00 00 07 04 00 10 02 00 01 00 (WANT-Event)

    71040us -> 01 00 07 00 00 03 01 02 00 00 00 FF (ACK-Command)

    168560us <- 02 00 00 00 07 04 00 10 02 00 03 00 (WANT-Event)

    168670us -> 01 00 07 00 00 03 03 02 00 00 00 FF (ACK-Command)

    468510us <- 02 00 00 00 07 04 00 10 02 00 02 00 (WANT-Event)

    468620us -> 01 00 07 00 00 03 02 02 00 00 00 FF (ACK-Command)

    597870us <- 02 00 00 00 05 04 00 40 01 00 (DONE!!!) -> This is the missing event!!!

    Why does it occur in your environment and my (and also Carlos) CC3000 does not send it !?!

    Differences, i see to my implementation:

    - Padding Byte is 0xFF in your case, in my case random

    -> Tried, no change, still no answer on last event

    - When reading data, i see you are always sending 0x03 (i was sending only 0x03 once as first byte, then always 0x00)

    -> Tried, no change, still no answer on last event

    - I have done all steps by keypresses, your sequence takes around 600 ms.

    -> Tried, no change, still no answer on last event

    Still don't know the difference. TI, help! Do you see something in traces from debug pins?

  • Hi Jia, hi Carlos et all,

    can you tell something if you use a self-built hardware or a TI platform. If TI platform, which one?

    @Jia: You had initially the problem, but now with TI FRAM it is running. Was this the initial platform, where you had the error? Were you meanwhile able to get it running on the initial platform?

    Could it be that the error results in a "wiring error", e.g. something like certain pin (beside SPI?) is wrongly connected?

    I meanwhile got a LM4F232H5QD, but it has not the connector soldered, which is needed to connect to CC3000EM...

    Best regards,

    Martin

  • We have custom built hardware. We still have this problem, but we've exposed the SPI lines on our board and used the TI MSP-EXP430FR5739 to perform the update to get the SPI traces I put up earlier.

    I highly doubt it's a wiring error. I can send TCP & UDP packets just fine, before and after the firmware update. It's only the wlan_start(1) function that hangs forever.

    We did try running wlan_start(1) on another piece of custom built hardware after the TI firmware got upgraded to the newest version (v1.19) and it returns fine.

  • Hi,

    as already reported, we also have the same problem and we use a standard TI's MSP430FG4618 Experimenter Board (http://www.ti.com/tool/msp-exp430fg4618).

    We have only added a pull-up resistor on the input pin (Interrupt Request) which has internal pull-up on the FRAM board and no pull-up on our board.

    Greetings

    Leo Reyneri

  • Any news on this topic from TI? Last life sign from TI on this topic was over two weeks ago...

  • Hi all,

    Does TI suggest something for solving this problem?

    Thank you and Best Regards,

    Mario

  • hi, 

    As far as I know they only asked me for the traces. But they didn't say anything. I continuous with the same problem and I don't have any idea about how to solve it. I am starting to think that it's a cc3000 firmware problem. Have you found out anything else?

    Best regards,

    Carlos.

  • So far, we also keep on having the same problem.

    I also strongly believe it is a CC3000 FW or HW problem; maybe timing or something else?

    Or incompatibility of the default configuration with the patch updater provided by TI.

    Without patch updates, we can scan the existing nets, but we cannot connect to them; it is claimed that without patches there might be connection problems.

    SO WE REALLY NEED TO DOWNLOAD PATCHES!!!

    But how?

    Can TI help, pls?

    Greetings

    Leo

  • Martin Maurer52841 said:

    You call wlan_start(1) which means start and "Host has patches". The CC3000 requests patches, but you always say: No, i have no patch. Now finally when CC3000 has requested all 3 patches (drv, bootload, fw), what shall it do? You say start with my patches, but then deliver no patches...

    Hi Martin,

    I got the same problem. Module was new.

    nvmem_read_sp_version -> 0 0

    wlan_start(1) hangs after fw request.

    wlan_start(0) worked, but SmartConfig not working etc.

    The solution was simple and corresponds to your idea:

    I exchanged the first initDriver(1) call with initDriver(0) in PatchProgrammer.c main.

    Flashing was successful and the later initDriver(1) calls after the FAT write already began to work.

    wlan_start(1) now works.

    nvmem_read_sp_version -> 1 19

    SmartConfig working

    Regards

    Matt

  • Hi evreyone,

    I have the same problem.I used the STM32 MCU.

    Can anybody give some advice?

    Ti guys?

  • Hello Jia Huang , 

    Can you tell me if you program the cc3000 using the executable file or the code provides by TI?

  • Hello,

    Do you mean that if you use the same process to program it like TI say but you always  set wlan_start(0) it works well? Can you confirm that?

    Best regards.

  • Hi Carlos,

    Yes, It can work well if I use wlan_start(0), But I use wlan_start(1), it  will not work well.

    My CC3000MOD module's SP version is v 1.8 .

    Now the new sp is v1.19, so I can't upgrade the patcher. Becuase when I use the wlan_start(1), I will wait here forevre.

    SimpleLinkWaitEvent(HCI_CMND_SIMPLE_LINK_START, 0);

  • Hi,

    Thank you for your answer, but my question is: 

    Did you update the cc3000 using wlan_start set to 0, wlan_start(0)? It's to try it too.

    Thanks you.

    Yours faithfully, Carlos

  • Carlos Lav��n said:

    Do you mean that if you use the same process to program it like TI say but you always  set wlan_start(0) it works well? Can you confirm that?

    Only the first initDriver(1) call needs a change (1->0). The later one´s worked without changes. It seems that wlan_start(1) begans to work after a successful fat_write.

    I can paste the code if you want.

  • Matthias Fleischer said:

    You call wlan_start(1) which means start and "Host has patches". The CC3000 requests patches, but you always say: No, i have no patch. Now finally when CC3000 has requested all 3 patches (drv, bootload, fw), what shall it do? You say start with my patches, but then deliver no patches...

    Hi Martin,

    I got the same problem. Module was new.

    nvmem_read_sp_version -> 0 0

    wlan_start(1) hangs after fw request.

    wlan_start(0) worked, but SmartConfig not working etc.

    The solution was simple and corresponds to your idea:

    I exchanged the first init_driver(1) call with init_driver(0) in PatchProgrammer.c main.

    Flashing was successful and the later init_driver(1) calls after the FAT write already began to work.

    wlan_start(1) now works.

    nvmem_read_sp_version -> 1 19

    SmartConfig working

    Regards

    Matt

    [/quote]

     

    Hi to all,

    The post of  Matthias Fleischer is very interesting. So do you mean that if in the PatchProgrammer.c main we substitute the first init_driver(1) with init_driver(0)  it works?

    Can someone  else confirm this information? This may be the solution to our issue.

    Thank you and Best Regards,

    Mario Demaria

  • Hi  ,

    Yes, it would be a great idea. I think that it will be interesting for me and for the rest people. 

    Thank for your answer.

    Best regards.

    Carlos Lavin.

  • Mario Demaria said:

    Hi to all,

    The post of  Matthias Fleischer is very interesting. So do you mean that if in the PatchProgrammer.c main we substitute the first initDriver(1) with initDriver(0)  it works?

    Can someone  else confirm this information? This may be the solution to our issue.

    Thank you and Best Regards,

    Mario Demaria

    That´s what I did. Someone else has to try it.

    It would be interesting to read nvmem_read_sp_version before, if you also get 0 0.

    If you look at the code in PatchProgrammer.c:

    1. initDriver(1)

    2. backup mac from eeprom

    3. backup parameters eeprom

    4. write new FAT

    5. wlan_stop

    6. initDriver(1)

    7 .....

    Point 4 seems to solve the problem, because 6 already worked.

    Regards

    Matt

  • Thank you Mattias,

    With that is enough for me to try it.

    Best regards.

    Carlos.

  • Hello Matthias,

    in my opinion your suggestion solves the problem only partly:

    (but at least it helps to solve some part of the problems)

    When the EEPROM is working (correct content, but containing an old (drv,fw) version), the results seem as you have written:

    - wlan_start(1) hangs after fw request (Martin: "which i think prevents original firmware update")
    - wlan_start(0) worked, but SmartConfig not working (Martin: old firmware seem then to have a problem) etc.

    But when the EEPROM is not working (due to bad content):

    - wlan_start(1) hangs after fw request.
    - wlan_start(0) hangs after fw request. (!!!)

    -> So at the moment for me no way known to recover via SPI

    So your procedure could work (TI, please confirm!), but when EEPROM is bad, it is no solution (TI, please help!).

    Matthias > nvmem_read_sp_version -> 0 0

    Interesting, that you get 0 0...what version was there in module before update? Is it a very old module? What is printed on top of module?

    nvmem_read_sp_version is not more working, when EEPROM is not more working, regardless of wlan_start(0) or wlan_start(1).

    lichy lichy > My CC3000MOD module's SP version is v 1.8 .

    Is it a very old module? I got mine with v 1.10. What is printed on top of module?

    Best regards,

    Martin



  • Hi Martin,

    Also my module has SP v1.8 and was produced in the 46th week of 2012 according to what is printed on top of it. So I think it is not a very old module but this Service Pack version may be too old for the newest WiFi Application (1.10.2 or 1.11) released by TI. As already said, my SPI and wlan_start(0) are working correctly, but I am not able to connect to an open AP and the wlan scan does not give completely correct results. I started to suspect that this is due to the too old SP on my CC3000.

    Thank you and Best Regards,

    Mario Demaria

  • Martin Maurer52841 said:

    Matthias > nvmem_read_sp_version -> 0 0

    Interesting, that you get 0 0...what version was there in module before update? Is it a very old module? What is printed on top of module?

    nvmem_read_sp_version is not more working, when EEPROM is not more working, regardless of wlan_start(0) or wlan_start(1).

    lichy lichy > My CC3000MOD module's SP version is v 1.8 .

    Is it a very old module? I got mine with v 1.10. What is printed on top of module?

    TiWi-SL Rev3. No versions printed. The module was brand new.

  • Hi ,

    I have tried your method and I have to tell you that it doesn't work. I changed the first wlan_start to 0 but in the second one it is blocking...

    Can you post your code to take a look just in case I am doing samething different? 

    Yours faithfully.

    Carlos

  • Hi all,

    Does TI have news about this issue? Can TI please give some help since the problem is really important and is shared by a large number of people?

    Thank you and Best Regards,

    Mario

  • Hi all,

    I have reached the same place each of you is at and have the same initial problem.  It is really frustrating at TI's apparent lack of support for their products.  It is hard to imagine staying in business with such disregard of customers.

    Sorry about the rant, I will now get on with the business at hand.

    Now, my thoughts.  I have read through all the posts here and have a couple of thoughts and curious to see if anyone else has thought about or tried the following.  I think we need to dive into the host driver code and possibly make some changes to it.

    Several posts back, there was a great post showing the HCI commands and events up to the lockup event.  I will repeat the list here with some comments:

    HCI_CMND_SIMPLE_LINK_START command and confirmation

    -- looks good here

    HCI_EVENT_PATCHES_DRV_REQ command and confirmation

    -- by the name of the event, it appears it is requesting a driver patch download.  It appears that there is no such download in the event handler.  Is it possible that some code is missing there to download the patch?

    HCI_EVENT_PATCHES_BOOOTLOAD_REQ command and confirmation

    -- this seems to be out of place with the others.  It seems to me that it should be before the driver patch (or not at all).  Should this be a special case where it should try a special boot that is not patched?

    HCI_EVENT_PATCHES_FW_REQ command with no confirmation

    -- is it waiting for the firmware patch to be downloaded?  The code does not seem to download a patch.  Is it missing from the code?

     

    In some other threads, that if the HCI_CMND_SIMPLE_LINK_START is send with a 1 value, that the CC3000 will boot without loading patches from the EEPROM and will instead be downloaded from the host.  Based on that, I really believe that code is missing from that delivered by TI.  Or, could there be differences between versions of host drivers that is causing problems.  Has anyone looked into this angle yet?

     

    Thanks,

    Brent