• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 39 subscribers
  • Views 561 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CC3235MODSF: Issues with connecting while only 5 GHz channels are open.

CC3235MODSF: BUG: The long delay before connecting to the 5 GHz AP while only 5 GHz channels are open.

Alex Mercer
Prodigy 140 points
Part Number: CC3235MODSF


Tool/software:

To whom it may concern,

I have the problem with the connection to the 5 GHz AP while only 5 GHz channels are open, leading to the long delay before a successful connection. It takes approximately 40 seconds. So in this thread 2 years ago, I described the exact same problem, and the TI's engineering team accepted this behavior as a bug. 2 years passed, but the bug is still there and not fixed. When will the fixed SDK be released?

The second problem I am going to discuss is the channel/region problem. So, I have noticed the weird behavior when CC3235MODSF is trying to connect to some AP. For example, when I'm opening an AP from my iPhone 13 (channel 6; 2.4 GHz), the CC3235MODSF can't connect when the EU region is set, but when I set the US region, suddenly it works with no problem even though both of the regions support this exact channel. I guess this is a bug. 

BR,

Alex

  • 0
    TI__Guru 64555 points

    Hi,

    In the past we had SDK released on a quarterly cadence but it has been a while since it happened since it is now on an LTS type of releases.

    Not sure when the next one is but I am also not sure if this one has been ever fixed (the guy that answered you is no longer in TI so I cannot verify it either).

    As for the 2nd issue, it does sounds strange if you are using the same channel.

    it could be that iOS is using a different setting for different country codes but I haven't tested myself.

    can you show what it says when scanning? how does the AP looks with each country code?

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 140 points

    Hi Shlomi,

    Can you verify the first issue, because I have found this link where the bug is indicated as will be fixed in the release of SDK 7.30. Maybe TI would release a new one in the future.

    As for the second one, I am sure that my iPhone is starting a 2.4 GHz AP on channel 6. I have checked it multiple times, but I cannot be sure which region settings it uses. I guess it could be that the iPhone somehow uses different region-related settings (like US), so the CC3235MODSF chip can't connect to it using EU region settings. How can I be sure if it is indeed iPhone's problem and not TI's driver bug?

    I can tell you that device is not getting any SL_WLAN_EVENT_CONNECT/SL_WLAN_EVENT_DISCONNECT events from SimpleLinkWlanEventHandler.

    Shlomi Itzhak said:
    how does the AP looks with each country code?

    What do you mean by that? Do you want me to do some tests with different region settings applied to CC3235MODSF, while scanning iPhone?

    BR,
    Alex 

  • 0 in reply to Alex Mercer
    TI__Guru 64555 points

    Hi,

    As for the first item, as I mentioned, I really don't know but if you say it still exists then it still needs to reproduced, debugged and fixed. I don't have dates I can share.

    As for the 2nd issue, I only have iOS 15 and I can connect from my SimpleLink device when set to either of the country codes (US, EU and JP). Not sure what happens with iOS 13. If you have a sniffer, I can take a look of the country code information element it reports on the beacon.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 140 points

    Hi Shlomi,

    Sorry for the late response. We were on holiday the last week.

    1) The problem still exists, and it is very problematic (long delay before successful connection) when AP's SSID name is the same for the 2.4G and 5G. We need to connect to the AP with the 5G band only, so we disabled all scanning channels for the 2.4G as suggested in this forum, and that's where the problem began. Somehow, a ~40s delay occurs before a successful connection, which is weird. Kobi reproduced the issue back then, but it is still not fixed.

    2) I have tried to reproduce the problem again, and now it works as intended, but I don't know why. I am sure that I couldn't connect to my iPhone with EU settings, but now it works. I will let you know if something weird is going to happen.

    BR,
    Alex

  • 0 in reply to Alex Mercer
    TI__Guru 64555 points

    OK, if you can make #2 reproduce, let us know.

    As for #1, do you have any sniffer captures or/and NWP logs?

  • 0 in reply to Shlomi Itzhak
    Prodigy 140 points

    Hi Shlomi,

    Sorry for the late response.

    No, I do not have any of the logs. Could you reproduce it?

  • 0 in reply to Alex Mercer
    TI__Guru 64555 points

    you mean #1, right? the 40 seconds delay.

  • 0 in reply to Shlomi Itzhak
    Prodigy 140 points

    yes, exactly

  • +1 in reply to Alex Mercer
    TI__Guru 64555 points

    Hi,

    I somehow reproduced something similar like the original thread.

    what happens is that if 2.4GHz channels are masked out, the initial scan is not getting triggered and the next one is, but it is by default 60 seconds later.

    the only workaround I could find for now is to set the mask of the 2.4 even with a single bit (e.g. for channel 13 which is the least congested). But any other channel would also do.

    This way, you can narrow down and scan fast the 5GHz and connect.

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 140 points

    This is exactly what we did to temporarily fix the problem, but I assume that TI should implement a comprehensive fix to the problem.

  • +1 in reply to Alex Mercer
    TI__Guru 64555 points

    Oh, I didn't capture that you had the workaround.

    For a fix, I will need to see since this legacy part is on LTS mode which means it takes more time to gather fixes and then come up with a servicepack that aggregates few fixes.

    Shlomi