Idle current for Wilink 8 Software Release R8.5 in combination with a WL1833 based module...

Hi Søren,

Let me check on this and get back to you.
Can you please confirm the below?

1. Which role are you running on the wl18xx side? (AP/STA)? Which band (2.4G/5G)?
2. If STA role, does it occur with all APs?
3. Idle/Suspend current: I assume you mean the wl18xx is connected ?

Regards,
Gigi Joseph.

Hi Gigi,

Thanks for the fast feedback, I should had included this information initially as well. Sorry for not doing this, but here we go :-)

1) I have only been testing current consumption in STA mode. I just briefly checked that AP mode works as well (i.e. that I could connect another device to it). Current is high at 15mA both at 2.4G and 5G operation if I use the "newer FWs". With the R8.4 FW I think I only tested at 2.4G, so I guess FW R8.4 and 5G operation strictly speaking is "unknown", despite my feeling would be it being low (4mA)

2 & 3) All testing have been done towards the same Cisco E3200 AP, and the increased current is seen in all three cases:

• WiFi Enabled and unconnected
• WiFi Enabled and connected @ 2.4G
• WiFi Enabled and connected @ 5G  

I have only tested towards this single AP, and expect it to behave fine, as it as said show 4mA using the FW from R8.4. Not that it tells a lot, but I just wanted to mention. This being said I can see what I can do test towards another AP and let you know if you find it important?

One additional comment which hit my mind over the night is that I still use the original WPA supplicant code from "old" TI Android 4AJ2.5P2 release. I don't think it's important (as I as said can connect, etc, so the code seem to behave well), and I don't expect the WPA code to have any influence on this low level power saving item (please correct me if you think I'm wrong), but thought I would mention it being a potential unknown which we as well should consider?

Please let me know what you think and if above give you any better feeling for that the problem might me. Still my only single bullet item changing current is related to using the R8.4 FW (4mA) contra any newer FW (15mA). Hoping above give you some additional idea for debugging/investigation?

Best regards and thanks again
  Søren
 

Hi Søren,

This is actually contrary to our results.
With the Linksys E3200, we got 1.293 mA (2.4G) and 1.562mA (5 G).

Besides, for "WiFi enabled and unconnected" state, the device should be in ELP at all times. It seems with your results that it is not.

Can you please share firmware logs for each scenario for further analysis?
The procedure to obtain fw logs is available at: processors.wiki.ti.com/.../WL_glogger

Please let me know if you need any further assistance.

Regards,
Gigi Joseph.

Hi Gigi,

Thanks for your fast feedback. Good to know that stuff is supposed to be at low current with R8.5 release (Did you test on WL1833 chip and/or shouldn't this matter? Maybe asking "stupid", but thought to better ask to be 100% sure that it somehow wouldn't potentially be a chip difference I'm hitting). I assume your testing is done with a "clean Linux build" from the R8.5 WiFi release (not using Android) - Right?

I will look into getting the logger going and share logs with you ASAP. Hopefully sometime by tomorrow. As Easter is coming up, can I kindly ask you to share a working log (with indication of important items to look for), as I can then try to compare my log to this, as well as upload them here?

Best regards and thanks in advance
  Søren

Hi Soren,

There was one change the to wlconf file that was done to improve WoWLAN current across a range of access points in R8.5. In my case I saw worse power numbers in R8.4 vs R8.3 that was then recovered by this patch. In R8.4 there was a huge range of WoWLAN behaviour across different APs (some great,some bad) with all their different timings. This patch was to reduce a timeout being triggered which was happening in the bad cases.

Can you check the value you have for that field in the actual wl18xx-conf.bin that you are using?

Iain

Hi Iain,

Yes, I saw above change, and I have played with it as well, but it seem to make no difference what so ever for my setup. Secondly my feeling is that my higher idle current feel more "static" than "waking up like", although I have to admit that I have only monitored that the OMAP isn't woken up and monitored power consumption on my power supply (updating like 4 times a second), where it seem rock stable at either like 4mA or 15mA (depending on FW). In case of any burst wake-up currents  the current shown on power supply typically seem to jump a bit around...

As said I see the increase based on the differences in the two firmwares mentioned in top of thread (FW 8.9.0.0.17 contra  FW 8.9.0.0.24), but I can't get it closer than this, as I just have these two binaries in two successive commits in the official FW git repo?

Any chance I can ask you to look into what might have changed in between here, as I guess we based on this should be able to get a clue to why I see increased current and as well maybe what I need to do to get it fixed?

Best regards and thanks in advance
  Søren

Hi Soren,

When we do a release we test it against ~150 APs. In the R8.5 release 90% of the APs tested had a connected idle consumption between 600uA and 4mA - including the cisco/linksys E3200.

Our test setup is the AM335x EVM + WL1835MOD running K3.12 Linux from SDK7.

Which module are you using as there is not a TI module with WL1833? Does it have an internal fast clock? Connected Idle while entering sleep also relies on 32k clock accuracy so perhaps that could be a bit off and R8.5 tightened up some timing.

On a more pragmatic level do you have a need for any features in R8.5? If you use R8.4 SP1 you have all the support you need for current EN300328 testing and so could go to production with that.

Iain

Hi Iain,

Sounds good. Module we use is from Murata (LBEP5CLWMC) and contain the HF clock internally (please read start of post for all these details). Wrt the 32kHz external I use the same with WL7 and haven't seen any problem here. Likewise R8.4 release seem to behave well, so I doubt that one being "root cause".

Isn't it possible for you to find a change log to see what happened to the FW between the two mentioned releases (FW 8.9.0.0.17 contra FW 8.9.0.0.24)? I would really like to know to try to understand the problem better, as my fear is that problem somehow only exists on WL1833 (i.e. none-MIMO version, where as all your TI testing it done at MIMO version? :-)

Wrt R8.5 contra R8.4 release I as such don't care as long release is supposed to work and can pass EN300328 certification.
Should I just checkout and use R8.4 for all gits, except FW-git for which I guess I should use R8.4_SP1 tag? Do you have a link to any release note for the R8.4_SP1 release?

Best regards and thanks again
Søren

PS: What is root cause for SP1 release? Fix for the EN300328 certification test failing?

Hi Iain, Gigi,

Sorry for "pushing", but can I kindly ask you for some feedback on above questions/comments wrt SW release R8.4_SP1, as well as any further information about what might have happened to the FW between the two commits where I see significantly change in current draw?

Best regards and thanks in advance
  Søren

Hi Soren,

R&D have looked at the changes between fw 0.17 and 0.24 and can't identify anything obvious that would trigger a change in behaviour. Additionally we don't have an OMAP4 + Android platform to see if there is a subtle issue there, all our testing is on AM335x + Linux.

The only pragmatic solution I can see is to try the firmware from R8.4SP1 (fw 8.9.0.1.17, git.ti.com/.../R8.4_SP1) which has following changes

SUT: traffic drops to zero for a few seconds during stability runs with key-rotation

CLUT with BT coex: FW Recovery occurred in two scenarios as CLUT + BT

Multirole Stability: SUT running traffic might disconnect from AP after several hours

APUT DFS: False radar detection on DFS channels

FCC/TELEC/ETSI: Adaptively test might fail certification

BT Coex – AFH channel list from the WLAN side is not accurate on some channels.

PLT: RX Simulation: Fix wrong MAC addresses comparison (Allows running RX simulation not only vs. AP)

 

Iain

Hi Iain,

Thanks for info. Sorry for my slightly delayed reply. Last days have been fully booked :-)

I will prepare going for compliance with 8.4SP1 FW, and then we can continue debugging from here...

Any chance you can get to try a WL1833 chip on the AM335x platform (preferable with Android), as my feeling is that it's more chip than platform dependent (but of cause just my feeling - being a former TI'er as well, although some years back :-))...

Next to above I will as well look into what I can do to provide you FW logs from the FW for use to continue investigations...

Best regards and thanks again - Your help and support is highly appreciated - Enjoy your weekend
  Søren

Hi Soren,
Under linux you can use the script /usr/sbin/wlconf/configure-device.sh to make sure your wl18xx-conf.bin file matches the wl1833 module you have. I hope it also runs under Android.
This will make sure the silicon is configured with the expected setting for a wl1833.
Iain