CC3135MOD: CC3135MOD

Hi Gasper,

We'll need some time to look into your testing and results, but I a question. The 4.5mA and 7.5mA figures seem high. Are you including other devices in these current measurements? Would it be possible to isolate the CC3135 for these readings? 

We do see through testing that connecting to a 5GHz AP does use less current, however 3mA does seem like a lot. I'll look into this further and provide you an update. 

Hi Sabeeh,

The info in the post contains the overall consumption of our entire device and we can't isolate it since we have a WiFi module soldered direclty to our PCB. There is still a 3 mA relative difference between 2.4 GHz and 5 GHz on the same device.

The document (PDF) that was attached contains only the consumption of the CC3135 WiFi module (measurements were done on the BOOSTXL-CC3135).

Hi Gasper,

Thanks for that information. Are you trying to understand why 2.4GHz is 3mA higher? Or is the power increase in the later service packs a concern?  

FYI Downgrading the SPs should be possible, just up to a particular version. Much older SPs can not be used. 

Hi Sabeeh,

We need solutions for both. The first priority is not to understand, but to get a solution - the service pack update ASAP, which fixes both of them.

You need to be aware that WiFi consumption takes a significant share in overall current consumption calculation. The whole products line design, including use cases and target market, is based on low consumption.
We are not in a position to align our products autonomy time specifications because of increased consumption introduced with your newer service packs.

chromechrome

Hi Gasper,

Understood. I would like to recreate your issue on our side so that we may be better able to assist you. In order to do this, could you also provide WiFi sniffer logs and NWP logs?

You can learn how to collect NWP logs from section 20 "Debug" in this guide: https://www.ti.com/lit/swru455 

Hi Sabeeh,

I've captured four 10-minutes sessions.
Please take a look for setup details in CC3135_Consumption_comparing_FWs.pdf document provided in the initial message above.

It is about WiFi associated mode. In all four cases, the CC3135 service pack used is the "latest one" (as labelled in mentioned .pdf doc).
In those 4 setups everything is the same, except WiFi AP - there are:
1) UniFi on 2.4 GHz,
2) UniFi on 5 GHz,
3) Linksys on 2.4 GHz and
4) Linksys on 5 GHz.

The zip containing captured/sniffed data can be downloaded from:
drive.google.com/.../18cuqWxO48ojjkw4uALZfK5QIHkdZBlaa


Kind regards.

chromechrome

Hi Gasper,

I am working to set up the tests on our side and will respond by end of day tomorrow.

Best regards,

Jesse

Hi Gasper,

In order to best reproduce the scenario, can you share the .bin file of the old service pack you are using?

Best regards,

Jesse

Hi Jesse,

The original "old" service pack was uploaded to BOOSTXL-CC3135 by TI during production so I don't have the binary, but I can provide you with the version information reported by the CC3135:

NWP v4.1.0.27
MAC 31.3.1.0.5
PHY 3.1.0.17
ChipId 823132160
ROM 8738

I have also attached a ZIP file containing the oldest CC3135 service pack UCF from our repository that we've used.

This is also the service pack version I was unable to downgrade to.

cc3135.zip

I am also adding a screenshot of the configuration of the Uniflash for producing a service pack should you need it:

Best,

Hi Gasper,

I did my best to recreate your scenario (new and old service pack, 2.4 GHz and 5 GHz channels, DTIM 300, average current consumption in associated mode over 60 seconds) and I didn't observe a significant difference in power consumption between the different service packs. 

Please see a summary of the results from my testing below:

I also took a look at the routers we have in our IOP lab. We don't have the exact same Linksys router you are using, but we do have the Linksys EA6700, and it looks like it has the same wifi chipset as the Linksys EA6900 (the BCM4360). The current consumption numbers from previous testing with the Linksys EA6700 look normal.

Does your Linksys router have the same wifi chipset? Are you running the latest firmware on the APs?

Given that we don't see a regression on our side we don't plan to make a fix.

Best regards,

Jesse

Hi Jesse,

Since we're getting different results and the only difference seems to be in the APs and/or host firmware, I suggest we ship to you the two APs we're using along with the test devices that we use to verify this. Can you please provide the shipping information?

Also, since I wasn't able to downgrade the service from 4.12.0.1 to 4.1.0.27, and this is something that would be useful for us, can you please provide instructions on how to do this? Is it possible to achieve this via the host API or did you use Uniflash tool?

Hi Gasper,

Gasper Korinsek37 said:

Since we're getting different results and the only difference seems to be in the APs and/or host firmware, I suggest we ship to you the two APs we're using along with the test devices that we use to verify this. Can you please provide the shipping information?

I think there are more steps we can take to continue to debug without having to ship hardware. Unfortunately we aren't able to commit resources to testing your specific APs and test devices at this time, but I can continue to provide support here.

Could you please re-capture your NWP and MAC logs? I wasn't able to parse them correctly and they may be corrupted. With NWP and MAC logs we should be able to tell if the device is staying awake for a longer period to receive the beacons from the AP.

Gasper Korinsek37 said:

Also, since I wasn't able to downgrade the service from 4.12.0.1 to 4.1.0.27, and this is something that would be useful for us, can you please provide instructions on how to do this? Is it possible to achieve this via the host API or did you use Uniflash tool?

Yes, there are downgrade protections for OTA updates, but you can downgrade the service pack from 4.12.0.1 to 4.1.0.27 using UniFlash and a CC31XXEMUBOOST with the BOOSTXL-CC3135. Here are the binaries for the two service packs I used for my testing:

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/sp_5F00_4.1.0.27_5F00_3.1.0.5_5F00_3.1.0.15.bin

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/sp_5F00_4.12.0.1_5F00_3.7.0.1_5F00_3.1.0.26.bin

Best regards,

Jesse

Hi Jesse,

Thank you for the provided binary files.

I'll prepare NWP and MAC logs as you suggested.

In the meanwhile, do you have any tool that could be used for checking the integrity of the log files that I can use? In the past, we had remarks from TI that the logs are corrupted (which could be due to module power-on/off cycles), and having such a tool would help us to validate the captured logs before sending them to you.

Best,

Hi Gasper,

There isn't a tool to check the integrity of the log files, but double check that you're following the steps below to take the NWP logs using the CC31XXEMUBOOST.

When capturing NWP logs, you should be able to stack the BOOSTXL-CC3135 and the CC31XXEMUBOOST. Or you can not stack the boards and use 2 jumper wires to connect the GND pins and pin 4.7 (NWP) between the two boards. Then:

• Connect the CC31XXEMUBOOST to the computer
• Follow the terminal settings outlined in section 20.1.2.2 of this guide (connect to the fourth port for the CC31XXEMUBOOST in device manager) 
  • 
  • Configure the terminal emulation to work in binary mode
• Run your program on the CC3135

While your application is running, make sure the logs are being recorded and saved.

Best regards,

Jesse

Hi Jesse,

Thank you for your reply, please give us some time to prepare the new logs (should be ready early next week).

Best,

Gašper

Hi Jesse,

A set of new captured data is available at:
drive.google.com/.../1ZdVcBS-TRMbtNFB8xJ6r-x0k-NfLend4

This zip contains one captured session, lasting approx. 5 minutes. During this time the CC3135 module is in associated state only.
Please skim the details.txt for relevant hardware setup details.

Let me know if this dataset is of use for your further investigation.

Best,

chromechrome

Hey Gasper,

Looking at the MAC log, I can see that our device isn't missing many beacons at all. It is, however, receiving a lot of beacons with broadcast indication, which could increase power consumption.

I didn't see either of the MAC addresses for the CC3135 (34:03:de:11:bb:d6) or AP (78:45:58:61:be:88) from the details.txt file in the wireshark capture. Could you verify which MAC addresses we should be looking for in the wireshark capture?

Best regards,

Jesse

Hi Jesse,

Please check the new capture data set, available at:
drive.google.com/.../1DjU8moyuDPVqtkaYFZZ3BVdpIwmoQocg

There are four cases (subfolders) named:
* NewSP (new CC3135 Service Pack, power-on sequence with complete connecting to server steps, after cca. 1 minute switching down to WiFi associated state),
* NewSP_asoc (new CC3135 Service Pack, WiFi associated state only),
* OldSP (old CC3135 Service Pack, power-on sequence with complete connecting to server steps, after cca. 1 minute switching down to WiFi associated state),
* OldSP_asoc (old CC3135 Service Pack, WiFi associated state only).

Included details.txt file describes what "new SP" and "old SP" versions are.

Best,

chromechrome

Hi Jesse,

Thanks for pointing to this LSI bug in older Service pack.
True, this sleep length is longer for all but 100 ms setting.

Best

chromechrome