CC3000: When will the next patch be released?

Ivor Sargoychev said:

My team is currently blocked on a bug and I would like to know when will the next CC3000 firmware patch be released.

Thanks!

Even if it was tomorrow it may not contain a fix for the bug that is troubling you. Just a suggestion: you may want to query the specific bug :)

Thanks for the suggestion, Alan!

The bug is decoupling the AP scan initiation API from writing to the EEPROM. Today we have wlan_ioctl_set_scan_params(...) which does both. However the CC3000 is too unstable and frequently hands, therefore it is necessary to be monitored by the MCU and restarted when it does so. Upon restart the fore-mentioned method must be called in order to initiate an AP scan. But since this method writes to the EEPROM, it can only be called a limited number of times before it exhausts the EEPROM write cycles and bricks the CC3000.

Mr. Raghavendra Shenoy Mathav from TI confirmed that this is a bug that they are tracking, I just don't know when a fix will be available.

Hi Ivor,

In my other thread I had mentioned that we did not have such a bug in our list. "We do not have a bug that we are tracking to seperate out scan and scan setting."

I'm sorry if there was any confusion.

Thanks & Regards,
Raghavendra

Hi Raghavendra,

Sorry, I misread your response.

How do I proceed about filing this bug?

Hi Ivor,

Continuing discussion from the other thread. I would have to check on the feasibility of this request and get back to you.

Thanks & Regards,
Raghavendra

Ivor,

Can you elaborate on this failure mode. Are you saying that the CC3000 can only do a limited number of AP scans / initializations / connections before it's EEPROM becomes inoperable and stops connecting to access points? This seems like it could be a viable explanation for what I've described in this other thread. In my case everything was working fine, using a watchdog timer to reset the MCU frequently like once or twice a minute, but has wound up in a state where now it won't connect anymore... it would have connected to this access point on the order of 50,000 times before it failed.

Vic

If one or more of the following methods:

netapp_timeout_values(...)

wlan_ioctl_set_connection_policy(...)

wlan_ioctl_set_scan_params(...)

netapp_config_mac_adrress(...)

netapp_dhcp(...)

wlan_add_profile(...)

wlan_ioctl_del_profile(...)

are called on each reset, they would exhaust the EEPROM. Most EEPROM chips are rated at 100,000 write-erase cycles. After that they are usually over-engineered to handle another 20% extra write-erase cycles. After that the ones start becoming indistinguishable from the zeros.

My team stress tested one CC3000 by restarting and calling wlan_ioctl_set_scan_params(...) in a loop and it failed after about 117,000 restarts. Now we are running a second more elaborate test on a second CC3000 by calling the following  method in a loop:

void RestartCC3000(void)
{
    wlan_stop();
    __delay_cycles(1600000); // need this delay, otherwise CC3000 never starts

    wlan_start(0);

    // After restart in order to be able to scan we need to call wlan_ioctl_set_scan_params(...)
    uint32_t intervals[] = { 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000, 2000 };
    wlan_ioctl_set_scan_params(10000, 20, 30, 2, 0x7ff, -80, 0, 205, intervals);
}

This test takes about 64 hours to do the first 100,000 iterations and is still running. I will report the results once it completes.