It always got the same IP via smart config, even it configs with the different AP

Did you mean 192.168.1.5? 196.168.1.5 is not a reserved address.

No. Gateway IP address is showed up on smart config mobile app.

cc3000 always get 10.0.5.90.

I meant are you sure you have configured your second AP to dispatch correct IP addresses, since 196.168.*.* is incorrect. It has to be 192.168.*.*

Hi Ivor

Yes, that is my typo. thanks for your correction.

thanks

Gavin

Anyone met this issue before?

I am not sure if I am missing something but isn't it normal for a DHCP server to try and provide a client with the same IP address if it has a matching MAC address.

But I used the different wifi AP to do smart config, it should be dispatched the different IP, right?

Hi Gavin,

From your initial description it is not clear precisely what you are doing - please provide a more detailed description. For example it is unclear if you are using 2 APs at the same time or a single one and you are changing its IP address. Also what APIs are you using to delete the profiles? If you are using a single AP and changing its address from 10.* to 192.168.*.*, how are you resetting it? How are you sure that the IP has changed indeed? If you are using an iPhone or an Android phone for the AP, what software is it using?

If you have a system where your 2 AP's have their own internal DHCP server you would expect to see different IP addresses for your leases. But if the DHCP server is located outside your AP's and is the same in both your test cases you would expect the same address in both cases.

HI Ivor

Please refer to what I did on this problem.

1. iphone connect to wifi ap and get IP: 10.0.*.*

2. do smart config via smart config app on iphone and cc3000 get IP:10.0.*.*

3. delete policy and reboot EVM board.

4. enable hotspot on one android phone

5. iphone connecte to hotspot and get IP:192.168.*.*

6. do smart config via smart config app on iphone and cc3000 get IP:10.0.*.* that is the same IP like before.

I expect that cc3000 can get the different IP from the previous.

thanks

Gavin

At step 6, what IP address does the iPhone show on the screen?

If it shows 192.168.*.*, yet it sends 10.0.*.* to the CC3000, try completely killing the iPhone app and then restarting it (by holding the start button and flicking it away or pressing the red close button on older iPhones). Maybe the app has some internal cache that is not cleared when the IP changes.

On iphone, (gateway IP address: 192.168.1.5) show on the screen.

Yes, I try to follow your suggestion, but cc3000 still get the same IP.

Ok, so the only possible place left where the old IP address can be remembered is the CC3000 EEPROM. How are you deleting the profiles? Are you calling wlan_ioctl_del_profile(255)?

Hi Gavin,

When you say deleting policy, can you please clarify if you are clearing the policy or deleting the profiles? Can you please show us how you are doing that?

Thanks & Regards,
Raghavendra

Basically, I use the sample code in SDK for testing.

Yes, I call the function to delete policy

wlan_ioctl_set_connection_policy(DISABLE, DISABLE, DISABLE);
vTaskDelay(1000/portTICK_RATE_MS);
wlan_ioctl_del_profile(255);

Hmm, I am starting to suspect the iPhone app once again. You see the old IP address is saved somewhere between step 4 and step 6. It cannot exist just floating in the air.

Can you go even further, like completely closing and uninstalling the iPhone app after step 4 and reinstalling it from the app store?

Hi Ivor

I don't think the problem coming from iphone app, the reason is that I can use it to config another cc3000 to get the different IP(like 10.0.*.*).

I suspect the policy in cc3000 can't be deleted clearly. How can I make sure the policy has been deleted?

I have no idea how to check if the policy still exists or not?

Do you have some suggestions?

thanks
Gavin

The CC3000 API cannot add or delete policies. It only has one policy that can be set. It can add and delete profiles though. All the related APIs with their descriptions are in wlan.h - you can take a look there. There is no API to read profiles - only to add or remove them.

Hi Ivor

Just like your mention, there is no API to read profile.

But I can use "nvmem_read(NVMEM_SHARED_MEM_FILEID, SMART_CONFIG_PROFILE_SIZE, 0, profileArray);" to get the profile data, it works.

So I read profile at two points, after smart config and after delete profile, but I get the same data (SSID, ...) in profileArray.

I expect that should be empty in profileArray. I guess that may be the cause.

thanks
Gavin

I just got an idea, if I clean this shared mem manually, maybe it can be written in another profile. So I use "nvmem_write(NVMEM_SHARED_MEM_FILEID, SMART_CONFIG_PROFILE_SIZE, 0, ZeroArray);" and then check it with "nvmem_read(NVMEM_SHARED_MEM_FILEID, SMART_CONFIG_PROFILE_SIZE, 0, profileArray);", the  profileArray is all "0". But cc3000 can't get IP after smart config anymore. Is there something wrong?

thanks

Gavin

Hi Gavin,

Couple of questions:

1. Does it always fail to get the right IP address with the hotspot? Or is it only this scenario?

2. Have you tried reversing the sequence here? Can you please try with the Android hotspot first, and check if the right IP address is acquired? After this try connecting to the other AP. Please let me know on what you observe.

I am not sure about the rate at which iphone is establishing the conection with the hotspot. I am trying to narrow down on the observations and check if the scenario falls within any of the limitations mentioned here: http://processors.wiki.ti.com/index.php/CC3000_Smart_Config#Limitations

Thanks & Regards,
Raghavendra

Hi Raghavendra

Just like I mention, I tried to write the shared memory but cc3000 always can't get IP via smart config.

So I re-flashed cc3000 FW/driver to recover it and I found the issue was gone.

I think this issue coming from cc3000, although I don't know the cause.

But I expect the issue will appear again in someday.

thanks

Gavin

Hi Gavin,

Thanks for your observation. This is strange, because assigning IP address should not really depend on changing parameters of EEPROM.

Please keep us posted if you observe this again.

Thanks & Regards,
Raghavendra