CC3000 stops working after a couple weeks of operation

Hi Brent,

Could be transients causing parts to fail, could be interference (longshot), could be a wrong connection, etc... I dont suppose you could share your schematic? Cant rule out other parts on board as the problem either. How many of these boards do you have? Can you compare voltages at specific points on the boards? Current?

Regards,

Aaron

Hi Aaron,

Please see attached file for the schematic of our product.  The CC3000 and related parts are on the last page of the schematic.

We have 10 other boards available.  (I need to make some mods to the boards before using them which will take a couple hours each - so, the are not readily available but accessible.)

I do have the ability to compare voltages at several points.  Current would be a more difficult proposition as the circuit would have to be broken to add in the measurement device.

Thanks,

Brent

PS - If you look in the forum, your messages get cut off.  I am not sure why but the bottom line is that others will not be able to read most of what you posted.  I had to go back to the email to see what you had written.

Hi Aaron,

I had some more information I wanted to add.  When you mentioned in your post that transients could be causing the parts to fail.  I wanted to emphasize the fact that I am not sure they are actually failing.  Does this failure mode you are referring to allow for the SPI interface to still be operational and the network scanning function to be able to work properly?  The parts are not completely bad, just the connection function being the only known bad part.  If the SPI didn't work or the network scan didn't work, it would be easier to point to a failed part of the chip.  This shows that the hardware is generally in working condition (unless the network scanning portion of the hardware is different that normal TX/RX functionality).  So is there different hardware for these functions?  Also, could there be a problem in the NVRAM that could explain this behavior?  Could there be a stack that is stored in NVRAM that has filled up that I am not clearing correctly?  Could there be a section that inadvertently got changed that I am not aware of?

I just wanted to mention this to make sure we were not barking up the wrong tree?  (Although I think it would be really good to have a design review of the schematics.)

Thanks,

Brent

Hi Aaron,

I noticed something today that I want to pass on.

I read the entire NVRAM to see if I could see any blatant issues.  Generally, things looked good.  However, there is one thing that I found that I don't necessary like.  The first entry in the FAT is 0x153, 0x01A0.  The second entry is 0x0051, 0x01A0.  It was initially written to 0x0050, 0x01A0 and 0x01F0, 0x01A0.  I believe the reason they are swapped is because of how the shadowing function works.  So, the problem I have is that the 0x0153 should be 0x01F3.  Do you agree?  Is there any way this could cause the condition I am seeing?

Thanks,

Brent

Hi Aaron,

I was finally able to fix this problem.  I still don't know what the problem is but was able to fix it.  I ran smart config, then I was able to connect.  I then removed the profile created with smart config.  After that, I was able to use the manual connect (wlan_connect) as before.  Not sure why this worked, but it did.

Brent

Hi Aaron,

My board broke again but this time I have more information.

First, some background info.  Because of limitation of smart config and the limit of 7 stored profiles, I am not using the CC3000 to manage or store profiles.  I am managing the profiles on the controller and then using wlan_connect to connect to the profile I want.

I noticed that the CC3000 was connecting to an AP when I didn't want it to.  I determined that the cause of that was the connection profile.  So, I deleted all profiles and changed the connect policy to have all policies disabled.  Once I did that, I could no longer use wlan_connect to manually connect to any AP.  That is when it stopped working again.  To correct it, I stored a profile and changed the connect policy to (0,1,0).  This fixed the problem and allowed me to connect to an AP and to manually connect to different APs.  I then deleted the stored profiles (without changing the connection policy) and then I can no longer manually connect to any AP.

It appears that wlan_connect requires at least one profile to be stored on the CC3000 in order for it to work.  Is this expected behavior?  If so, is there a way to work around that limitation?  Our application requires us to have control over which AP it connects to and when.  If this is not expected behavior, can you help me see what I am doing wrong?  (The only difference between a working and non working sequence is the addition of the add_profile command - at least once to store the profile.  So, the general sequence does work, just not without a profile stored.)

Thanks,

Brent

Hi Aaron,

Yet more information.

Once I get a certain AP in a given environment, I can connect to that AP at will using wlan_connect even after removing the profile from the CC3000 and disabling the automatic connect options.  It also appears that if there are other APs present in that environment I can connect to those also.  However, once I move to a new environment with different APs, I can't connect to them.  I need to go through a sequence (that I have not yet fully figured out) of adding profiles and enabling the automatic connect options before the wlan_connect command will work for the new APs.  I can then delete all the profiles on the CC3000 and disable the auto connect and still connect at will to the APs.  If I then move back to the original environment, I have to start over again.

Does any of this make sense to you?  What could be causing this?

Thanks,

Brent

Brent,

What do you mean exactly by environment? For example, if you have a number of APs that are visible to the CC3000, and then you add one or more, and/or take away one or more, does that constitute a different environment? Also, devices are moved to completely different locations frequently, and continue to work. These sorts of things happens all the time when we play with devices here and we haven't seen anything like that so far.

Regards,

Aaron

Hi Brent,

We have not encountered any of the problems you see, and am almost certain this is somehow related to configuration issues.

Stored profiles should not impact manual wlan_connect function. When you remove all profiles (0xFF), and also changed the policy to (0,0,0), it means that device will not try  to connect automatically (not to a stored profile, and not to the last connected AP), just as you mentioned.

In order to assist you, can you please send your code for review (the wlan part should be enough). I want to examine it, and see if something is wrong.

Also, is it possible for you to provide air capture when connection does not succeed. I'd like to check if probe requests are being sent to the requested AP, and whether connection just fails, or maybe the DHCP part.. please use open security AP for the test.

If I don't find anything suspicious/wrong in your wlan calls, then the next steps would be reading the profiles information from the EEPROM, and providing network stack (internal CC3000) logs.

Regards,

Tomer

Hi Aaron,

With regards to your last posting, by environment, I mean physically moving the device to a different location that has a separate set of APs.  I am not adding or subtracting APs in either environment; they are totally new APs.

In your environment, do you have the profiles stored on the CC3000 and one or more of the auto connect options set?  To mimic mine, you would have to have no profiles stored, all auto connect options disabled and use only wlan_connect to connect to an AP.

Thanks,

Brent

Hi Tomer,

I would agree that it is related to configuration issues but for the life of me, I haven't been able to determine what configuration parameter it is.

My code is shown below.  All wlan functions are stock functions and unmodified.

I will work on the other data for you.  A couple of comments, though.  It is not possible for me to open up the security on the APs I have available so I am always using secured APs.  Also, reading the profiles will not return anything valid since I have not stored any.  (I have checked to make sure.)

Thanks,

Brent

  resetCC3000StateMachine();
   
  wlan_start(0);

  wlan_set_event_mask(HCI_EVNT_WLAN_KEEPALIVE|
                      HCI_EVNT_WLAN_UNSOL_INIT|
                      HCI_EVNT_WLAN_ASYNC_PING_REPORT);

  setCC3000MachineState(CC3000_INIT);
  unsolicited_events_timer_init();

  return_value = wlan_connect((uint32)wl_type, (char *)wl_ssid,
                        (long)wl_ssid_length, 0, wl_key, (long)wl_key_length);

  if (return_value == -1)
    error = ERROR_WL_NO_CONNECT;

  __delay_cycles(6000000);

  if (error == NO_ERROR)
  {
    return_value = wlan_ioctl_statusget();

    if (return_value != 3)    // 3 is WLAN_STATUS_CONNECTED
      error = ERROR_WL_NO_CONNECT;
  }

Hi Brent,

no real fix, but an idea:

  __delay_cycles(6000000);

is a delay of around x seconds or so?

What, if the connection phase takes longer than x seconds? You return an error ERROR_WL_NO_CONNECT.

As I understood, if you want to connect to a new AP, it is first scanned and then connected to. When you already had a connection before, stored info is used (TI: Is this correct?). So connecting to a new AP could take longer.

If you always delete stored history (info about previously connected AP), does it always take so much longer, so long that you ran into timeout?

Can you perhaps check (endless for a test?), in case of error, if connection is established at all (without timeout)?

Something like

while(1)

{

  __delay_cycles(6000000);

    return_value = wlan_ioctl_statusget();

    ...and checking return value, display something...

}

Best regards,

Martin

Hi Martin,

I agree on your analysis of the connection taking longer.  I have addressed that in a slightly different manner.  While connected to my debugger, I put break points in a various places in the code to artificially add more delay.  This point was one that I put a break point at.  I waited up to minutes and it did not make a difference.  I also used the debugger to repeat the wlan_connect and the statusget commands (not necessarily at the same time - but different combinations) and that didn't make a difference either.

I did get a little more information last night.  I used wlan_add_profile to add a profile to the CC3000.  I tried using wlan_connect with the same profile - it failed on the connect.  I then changed the connection policy with all three options TRUE - it connected automatically to the AP.  I then changed the connection policy back to all FALSE and then tried wlan_connect and then reset the device to make sure the previous automatic connection was dropped - the connection failed again.  This tells me that:

1. the CC3000 can connect to my AP
2. the CC3000 didn't store the connection information
3. the wlan_connect path uses a different path than the auto connect path does
4. the wlan_connect does not look at stored profiles

I know the wlan_connect path does work on my device and it works for this AP because I have used it in the past.  I am not sure why it doesn't work now but it has to be something stored somewhere but I am not sure what or where that is.  Some kind of configuration parameter.  I didn't do anything explicit (that I am aware of) so it has to be some configuration parameter behind the scenes that is done automatically that I triggered somehow.  I would think that wlan_connect would work "straight out of the box" with default values but that is not what I am seeing.

In your case, was there anything special you do before using wlan_connect or is it that standard init, wlan_start, and then wlan_connect?

Thanks,

Brent

FWIW I've seen a similar problem. My Spark Core (beta) w/CC3000 connected effortlessly for weeks (months?) and then one day, bam ... nada. There is nothing I've tried that will get it to connect. It's like there was some sort of NVRAM overwrite or something (after a long time). I'm in the process of trying to build/DFU a clean bin but so far, no luck. And for all I know, doing a clean DFU won't fix any NV issues that are there. Sign ... 

Hi Brent,

wlan_connect should work no matter if you have a saved profile or not. If your policy is set to autoconnect, it will connect automatically to a stored profile, but once you issue wlan_connect, it will connect to the new AP.

Can you specify the exact parameters you put inside wlan_connect? 

To be able to help better, please share air capture. I'd like to see  the connection attempt and tell why it is failing.

Please try to provide network stack logs. If that may take more time, please provide the other information first.

Currently, I can't event tell if it even started.

David, 

Is it possible for you to share the EEPROM content? I will be able to tell if something is corrupted by seeing this information.

Have you  tried reprogramming the module (patch programmer)? This should help, although I think we should first understand the root cause of why this happened.

As requested from Brent, please try to provide that information as well.

Thanks,

Tomer 

Hi Tomer,

I have been unable to get a capture yet.  I have attached the cable and tried some suggestions from Martin but I have not been able to get anything captured yet.  I am still working on it.

Also, there is a lot of traffic on our network so I have not been able to isolate the connection request and the air capture.  From external indications, it appears that it isn't even trying.

Here is my wlan_connect command:

    return_value = wlan_connect((uint32)wl_type, (char *)wl_ssid,
                        (long)wl_ssid_length, 0, wl_key, (long)wl_key_length)

where wl_type is 0x2

wl_ssid is "ElectroNMonk"

wl_ssid_length is 12

wl_key is my key that is 9 characters long and it is a char *

wl_key_length is 9

Once I have the connection working, I can use the same command to re-attach but before I get that it working, it doesn't work.  It is the same command in both cases.

I will continue to try to get a trace but it looks like we are giving up on this method and trying something else.  The work-around that seems to work reliably is a three step process - 1.  delete all profiles, 2.  add the profile for the AP you want to connect to, 3.  set the connection policy to (0, 0, 1).  Not sure why the wlan_connect doesn't work and this does but we have wasted way too much time to get it working and need something to work.

Brent

Hi,

Does the AP use are trying to connect to use WPA security?

Can you please send the add_profile command parameters you're using when it works?

Please provide the EEPROM content. Best if you could provide all content, and not specific FILE IDs.

Regards,

Tomer 

In addition, looking at your previous post:

"The first entry in the FAT is 0x153, 0x01A0.  The second entry is 0x0051, 0x01A0.  It was initially written to 0x0050, 0x01A0 and 0x01F0, 0x01A0.  I believe the reason they are swapped is because of how the shadowing function works.  So, the problem I have is that the 0x0153 should be 0x01F"

This doesn't look good. The values can be swapped due to shadowing, and the 2 most lsb bits indicate valid and allocated entries. But, as you say, the initial values are "0x0050, 0x01A0 and 0x01F0, 0x01A0". These values can be swapped (0x01A0 represent the length), and can also be valid and allocated, which means, 0x0053, 0x01F3, but in any case you should not see 0x0153. 

As requested, please send the whole content of the EEPROM. 

Thanks,

Tomer

btw, does it happen with specific module?

Have you tried running the patch programmer again? Which platform are you using? Is there a chance this was corrupted during porting?

Thanks,

Tomer

Hi Tomer,

Attached is the dump of the entire NVMEM.  The format is there are 64 bytes per line.  The first number on each line is the address offset in hex.  The rest of the line are the bytes in hex format in incrementing address order.

To answer your questions from the previous several posts:

My AP does have security.

My add_profile command is as follows:
wlan_add_profile(WLAN_SEC_WPA2, "ElectroNMonk", 12, NULL, 1, 0x18, 0x1e, 2, "XXXXXXXX", 8);

When followed with enabling the auto connect, this works.  However, the wlan_connect without auto connect is as follows and does not work (repeat of previous post but repeated for ease of reading):
wlan_connect(WLAN_SEC_WPA2, "ElectroNMonk", 12, 0, "XXXXXXXX", 8);

I am not sure if this NVMEM file reflects the issues I saw earlier.  I have not looked at it in the details I have before but it should be good.  Just to be clear about that status of where it came from, this is the sequence I put my board through before outputting this file:
1. I have been using this board to go back and forth from a working configuration to a non-working configuration
2. A working configuration is when I use add profile and enable the auto connect.
3. A non-working configuration is when I delete all profiles, disable the auto connect, and use wlan_connect.
4. I verified the working configuration is still working and then:
5. I put the board in the non-working configuration and then verified it still does not work and then dumped the NVMEM.

This has been done on only one part because I only have one board working at this time.

I am using Windows 7 and have not found a terminal window that works in Windows 7 and supports the USB FTDI cable.  (Our board also has an FTDI chip and that may be the cause of some of my problems - conflicts.)
Martin sent me a terminal program but it was unable to open the USB com port.

I have not re-run the patch programmer lately but I have run it twice on this board (both to version 1.11) and the results were the in both cases.  I have done a verification where I dumped the NVMEM and tried to compare to the original patch files.  It did check out but I could have made a mistake in the process.  You may be able to double check that now that you have the NVMEM file.

I hope I have everything you asked for.

Thanks for the help.

Brent

Hi Brent,

According to the EEPROM, I can see that you're using DHCP, but not all parameters are zeroed (where in fact they should be when working with DHCP).

Can you please try the following:

memset (&pucIP_Addr, 0, 4);
memset (&pucSubnetMask, 0, 4); 
memset (&pucIP_DefaultGWAddr, 0, 4);
memset (&pucDNS, 0, 4);

netapp_dhcp((unsigned long *)pucIP_Addr, (unsigned long *)pucSubnetMask, (unsigned long *)pucIP_DefaultGWAddr, (unsigned long *)pucDNS);

I hope you'll get network stack logs by then, if that doesn't work for you either.

Do you have air sniffer?

Regards,

Tomer

Hi Tomer,

I tried the netapp_dhcp as you suggested but it didn't change anything.
It did appear to break my smart config path, though, which is unexpected.

Also, I am surprised that the values are not 0.  From what I can tell in the comments for the netapp_dhcp function, DHCP is the default mode.  I have not used static IP addressing ever so I would expect it to still be in the default mode.

No luck on the logging or sniffer so far.

Brent

Hi Brent,

Which platform are you using? Is it any of the SDK platforms that we release? We have several simple examples that shows manual wlan_connect and smartconfig operation which after completion use a stored profile.

If not, can you send the SPI data stream of wlan_connect command? Since there are not network stack logs yet, SPI capture would  be an intermediate solution.

Regards,

Tomer

Hi Tomer,

I was finally able to get logging to work.  Hopefully it will contain some useful information.

First, to answer your questions.  I am using Windows 7 and CCS.  I am not using any of your platforms because I have a custom board.  I used the CC3000 FRAM Sensor Application as my reference.  I have also used other examples and the forum to put together my routines that weren't in the Sensor Application. 

The log file is from the failed connection case.

Thanks,

Brent

Hi Tomer,

I have one more log file I would like you to look into.  This log file is from an earlier post.  When I changed the DHCP settings, it broke my smart config  routine.  If I used an older version of my smart config routine, I was able to get it to work but my current routine does not work.  I can't see any real differences between them from the CC3000 command perspective and was wondering if you can take a look at it and see why it isn't working.  The log file is from the current code and non-working case.

Thanks,

Brent

Hi Brent,

Thanks for the logs. I'll to provide my feedback by tomorrow.

Regards,

Tomer

Hello Brent and the TI Team,

We are having a similar issue with our cc3000 so we are really interested in the answer. We have been following this post since it was created and are desperate to come up with the solution.

Thanks!

Hi Dorse Ab,

I have no more news or progress to report.  Last I heard I should have had some feedback from the log files yesterday.

However, I have had some minor progress in various areas and also some data gathering I have done that may be helpful.  There is far too much information just to report it all here as I get it.  I also know that even though some symptoms may be nearly identical, the actual causes can be vastly different.  If you were to report what you do know - observations and failure modes - for your case, I may be able to help steer you in a direction that may help.

Thanks,

Brent 

Hi Brent,

Regarding "connect_logfile", I could see that connection did succeed, and that DHCP event (after 4 way handshake) was sent to the host.

The IP address is: 192.168.0.66. SSID = Elec.. I could also see that you added "Elec.." SSID as a profile, and connection occurred automatically..

Can you clarify why do you think connection failed?

As for the smartconfig log, I need more information.

Can you please send the firmware logs (there are 2 pins, one for network stack logs, and the other for the lower mac - firmware logs)?

Can you please tell if it always fail now? Did it ever work?

Which platform are you using to configure the smartconfig (java, iOS, Android)?

Can you send air capture?

Regards,

Tomer

Hi Tomer,

Thanks for your response.

There are a couple of reasons why I believe the connect_logfile connection failed.  First, when I try to "ping" 192.168.0.66, it fails.  (When the connection succeeds, this works fine - and yes, the router is programmed to provide a fixed IP address for this MAC address.)  Next, I can't create a socket - the command returns a failure when run.

In the smartconfig case, I will work on the log files.  It might take me a little bit because I have to get the environment back together again.  It was working at one point but there have been some changes made to my code that affected it.  The general succession of code is the same as a working case but for some reason does not work in the failing case.  So, I can't explain what actually caused it to fail.
The platforms used to configure are java and iOS.
The air capture is really difficult because of our environment.  We have a lot of background noise here and it is hard to filter all of it out so that it is really hard to glean the useful information from the logs.

Brent

Hi Brent,

The connect log file looks 100% functional. Can you please provide another capture where socket create fails afterwards? I'd like to understand why it fails for you. In the capture you provided, there were no further commands.

It's not a must, but if you can provide air capture synced with the log where it fails, it would also help. It will help me tell if the SYN packet was actually sent or not.

Sorry for the delay, I'm ooo, therefore my reply is delayed.

Regards,

Tomer

Hi Tomer,

Here is the same logfile but with the socket function call.

One other method of determining a failed connection that I forgot to mention is the wlan_ioctl_statusget function call.  It returns a 0 in my connection failures and a 3 on the successful connections.

Thanks,

Brent

Hi Tomer,

Here is the firmware log for the smart config failing case.

Brent

Hi Brent,

The network stack log you provided includes manual wlan connect and the connection fails. This is the reason why bsd socket doesn't end up successfully. In the previous log you provided, it connected automatically by adding a profile and policy was set to auto connection.

I believe the reason it doesn't work for you is that because you use wlan connect to WPA security instead of WPA2. You should use: 

#define      WLAN_SEC_WPA2 (3) and not

#define      WLAN_SEC_WPA2 (2)

I believe you used the constant "2" instead of "3". Please check this, and re-test.

Regarding the firmware log, it doesn't open correctly. Please re-check.

Thanks,

Tomer

Hi Brent,

I appreciate your detailed answer, and we are already working on part of the things you mentioned for our next generation solutions. This includes better documentation, much more examples, ease of porting, etc..

We will also support "read profiles" API which will provide all information of the stored profiles. 

As for the smartconfig, the purpose was to simplify the process as much as possible, where the user only has to call one API to activate it. The purpose (in the application layer) was not to make it complicated, nor hiding it from the user, but rather start a process, and upon completion to give indication of success/failure. 

As stated at the beginning, we are working already to improve our next generation solution, and will do our best to accommodate your comments. If you further questions/issues with the device, please let me know.

Regards,

Tomer

Hi Tomer,

just some questions/clarifications:

- What do you exactly mean by "next generation solution"? Is it a new software release for CC3000 or a new chip (e.g. CC3100)? I don't want to ask for a time, when it will be available, if it is worth waiting for it, what it will additionally support, similar prices, pin compatibility, SPI format compatibility... no, information will come by time...

- In my opinion support of a "read profiles" API would be an easy thing also for existing CC3000. As far as i know all profile information is stored in EEPROM. EEPROM could be read back, so what is missing, is to decode this information back to "human readable form". No change in CC3000 (hardware and software), no change in existing API, simply an extension of host code, where each user can decide by itself (like for tiny driver) if it wants the new APIs or not...

- I agree, it is effort on TI side to define and implement such a "read profile" API. TI perhaps does not want to spent this effort or just have no free resources to do this. If there is just a documentation of every bit in EEPROM (which is perhaps already available inside TI to implement CC3000 software) it could be, that there is even no effort by TI, because Community can implement it.

- Simplification is a good thing. It makes life of developer easier, because easy sequences are easier to understand. But hiding helpful information (like reasons why something fails, not documented error codes, not documented content of EEPROM, not documented SPI frames, encryption of logfiles, ...) creates big effort

-> for TI to try to find out (even for easy cases) what is running wrong (if developer can provide encrypted logfiles, air traces, source code, how CC3000 API was used, EEPROM content...)

-> during software development (you don't know why something is not working and there is now efficient way to find it out)

-> for support people (customers report that something is not working, but you have no clue why it failed, because black box (CC3000 system) just says nothing or just says "failed", leaving field of errors huge as our universum)

-> for end customer to find out why something is not working, send email/phone to support, trying out this and that and finally sending product back because not getting it to work and change to product of other company.

Just one easy example:

Customer enters wrong key. The one which installed the router years ago has written down only 8 of the 9 digits of the key. Tried to use it multiple times, but connection of device with CC3000 simply does not work (which is perhaps the most common error). Think about possible variants, what could be wrong (only to mention some of them: no AP found, AP connection too weak, wrong AP selected, wrong encryption variant, wrong key, not compatible AP, AP does not want this device e.g. MAC filtered...).

Now customer asks support (hopefully at least with some knowledge in this area): Connection not possible what shall i do? Ok, support can have a list ready, FAQ, 1000 common customer errors.

Support ask manufacturing company, developer: Connection does not work, what to do?

Developer: Oh, i don't know, could be everything. Let's ask TI in E2E forum.

TI in E2E forum says: Do an AirTrace. Do a log from debug pins. Show us your relevant source code. Use latest firmware.

Is this really the way to go? Shall i send end customer equipment to do this kind of traces just to find out, oh, he/she has entered the wrong key. (Just kidding - Important customer, wants immediate solution: do I need to do a business trip to find out the same.) What would it be easy to get error x which tells key is wrong (ok, perhaps it is not easy to find this out, i don't know) and display to customer "Key is wrong". He/she can solve the error by himself/herself, calling the one who installed the router to clarify this problem.

At the moment (just tried it out), with a wrong key, encrypted connection, DHCP, i get a WLAN_CONNECT event from CC3000 following by a WLAN_DISCONNECT event some seconds later. As software developer, do i really need to detect this situation, to interpret it as possible "key wrong"...? Do I need to test all of this situation, to see how CC3000 behaves and implement some host workaround (and use the crystal ball) to decide in what error situation I could be?

It would be nice to get an advice: "do it different, than all is no problem".

I would like to thank for every bug fix and bug report, from TI and all other community members, for every problem that is highlighted and fixed before it reaches the end customer. Each bug which is fixed earliest as possible is saving money for everyone.

Excuse to Brent for hijacking the thread...

Just my 2 cents...

Best regards,

Martin

Ok, no answer in over 3 weeks.

Hi all

I dont mean to Hijack this thread, but it seems a lot of the information is related and I dont want to duplicate a thread.

Hardware Information: 

We are using a custom board with a atmel UC3 mcu and the CC3000. The board has a 3.0V supply and is used by the MCU and the CC3000. VIO_HOST is connected to 3.0V as well. The CC3000 modules are CC3000MODR

Firmware Information:

The service pack version I get from the CC3000 with nvmem_read_sp_version() is 1.10 and am using a ported spi driver that was derived from the CC3000FRAMSensorApp. The host driver version I am using is 1.10.1 (swrc263a). I have never programmed or attempted to flash the firmware with the patch programmer.

I have had two boards that dont want to connect to the AP anymore after countless successful connections.

On these two boards I still have SPI communication with the CC3000 and the initialization is successful, it just doesn't connect to the AP anymore.

I am using the auto connect functionality and my init is done as follows (pseudo code):

• wlan_init
• wlan_stop
• Delay for 2 secconds
• wlan_start
• Delay for 2 seconds
• Delete all profiles
• Delay for 2 secconds
• Clear connection policies
• Wait for disconnect event, timeout if not received in 5s
• Add a new profile (with AP info I want to connect to)
• Delay for 2 seconds
• Set connection policy for auto connection
• Delay for 2 seconds
• wlan_stop
• Delay for 2 seconds
• Wlan_start
• Delay for 2 seconds
• Wait for connected event before issuing Dhcp connect event

Hi Thomas,

Did not across such a scenario. The steps seem ok to me, unless something changed at the AP side. Did something like this happen with the latest SDK-1.11?

Thanks & Regards,

Raghavendra

Hi Raghavendra

Thanks for the reply

The AP stayed the same the whole time, and when I program a new board with the exact same firmware it starts up and connection is OK.

In terms of the latest SDK, I do not know, as I ran into problems in the beginning of development; opening a socket and sending UDP packets using the latest Host driver version with my version of the Firmware on the module, so I switched to the Host driver version that seems to correspond to my firmware version on the CC3000.

Any advice to isolate the problem would be appreciated; as I don't really feel comfortable releasing the boards with a problem like this hanging over it.

Regards