CC3135MOD: Consumption increases after some days

Part Number: CC3135MOD
Other Parts Discussed in Thread: CC3135,

Hello,

We have a test setup of 20 equal devices, containing CC3135 module (NWP 4.11.0.0, MAC 3.7.0.1, PHY 3.1.0.26, ROM 8738). I have detailed report about the setup, procedure and test results (available to you, if needed), so, below is just a summary of the observed issue:

It happens now and then, after several days, that on random device(s) consumption increases significantly, average current from 6.5 mA to 16 mA. It has been drilled down that CC3135MOD is the one which increases its consumption. I'd like to underline that the module itself operates normally all the time, however, consumption is something we must keep low for our devices.

In order to restore the consumption back to normal level, it is enough to de-associate the module and associate it back to WiFi AP. Consumption level is then again normal for several days (interval varies).

Next to mentioned test report with more details, I can provide you also captured WiFi traffic during increased consumption mode and after it was restored back to normal. Do not hesitate to let me know what data should I provide you for effective investigation.

I'm wondering if this is a known issue to you and if there are any activities going on to solve it.

Thanks and best regards.

  • Hi,

    This may be an IOP issue with the AP.

    what vendor and model are you using?

    an air sniffer would be good here but also an NWP log and MAC firmware log.

    Please try to capture an NWP log (see details in chapter 20 of the programmer's guide (https://www.ti.com/lit/swru455).

    A MAC log is also required. The procedure is the same as for NWP but the pin is 60 and not 62.

    since it is cc3135 and not cc3225 you do not need to mud anything on SW and you have these like mixed out already.

    shlomi

  • Hi Shlomi,

    Thanks for the quick response.

    Please find attached zip containing debug output of MAC and NWP. We're still working to capture the air sniffer logs.

    Attached are also results of current consumption measurements. All logs were taken at the same time. Initially, the WiFi module was connected to a server, then I started to change mode back to power-off, and back to fully operating mode. You can see consumption steps of these events in mentioned current measurements.

    Do not hesitate to let me know if you need any further details (next to air sniffing data).

    Thanks and best wishes.

    CC3135_Consumption.zip

  • Hi,

    The MAC logger shows that your environment is full of multicast/broadcast frames.

    Following every beacon (102.3mSec separated), the MAC firmware gets many broadcasts in a chain and this is what keeps it fully awake in high power.

    Air sniffer logs would prove it as well.

    In this environment there is not much we can do (other chipsets should also behave similarly).

    Regards,

    Shlomi

  • Hi Shlomi,

    Thanks for your answer.

    I'm not sure these broadcasts are the (main) reason for increased consumption.
    What makes me skeptic is that we have a setup of 20 equal devices, physically located close one to another (on the same desk). They have equal WiFi configuration (same SSID, DTIM, etc.). However, observed increased consumption occurs randomly, just on few of them per day.

    The consumption level drops back to normal immediately after a device is de-associated and associated to AP. When this "recovery" is done on the first device, this doesn't have impact on remaining ones, of course. The de-association & association needs to be performed on each.
    Afterwards, these devices have normal consumption again for several days... and in the mean time increases occur on few others. Randomly.

    If broadcasts were the reason, I'd expect that all devices would behave very similarly.


    The logs I sent in the previous message were captured on another hardware with exposed debug outputs (furthermore, located in another room, connected to another AP). What we did was to move this "debug device" next to mentioned 20 ones and applied the same settings to it.
    You can expect new complete set on logs from this device in the upcoming days.


    Best regards

  • Thanks for the update.

    I agree that broadcasts are not the only contributors since other devices should also experience similar behavior.

    Moreover, re-association where broadcasts are still transmitted should have cause high power consumption immediately.

    Let me know when you have more logs.

    Shlomi

  • Hi Shlomi,

    I set some automatic scripting and have captured a suspicious event. It lasts just 3 seconds (see consumption graph below), but this data might be useful anyway.

    The logs available in zip https://drive.google.com/file/d/1jis5fFpm2F-ekR-m2Highk8eNvnvKkK8 were collected 30 minutes, the event occurs after 7 minutes.

    The output.csv file contains current consumption data, this event appears in it after 421 seconds (timestamp 421094.56). Logging is started from a script, launching log-grabbing item one after another, consequenly, there might be slight time offset between related items in the files (< 1 sec, I believe).

    Any feedback is appreciated.

    I'll continue to collect logs for critical events...


    Kind regards

  • Hi,

    Logs are a little corrupted so hard to see. Also, the MAC log seems short.

    Can you elaborate what is the MAC address of the station and of the AP?

    Shlomi

  • Hi Shlomi,

    Thank you again for the quick response.

    The device's MAC is 34:03:de:11:bb:d6, and AP's MAC 01:00:5e:00:00:fb.

    It could be that reading UART data approach I'm taking is not suitable for this baudrate. I'm going to investigate this.

    Kind regards

  • Hi,

    MAC 01:00:5e:00:00:fb is just a multicast, not the AP MAC.

    Your AP according to the DUT is Ubiquiti with MAC ba:fb:e4:84:82:21.

    I do not see something strange in the air sniffer after 420 seconds but the problem is that the gLogger also shows me the TSF of the AP it is connected to and the TSF is way off the one that appears in the sniffer for Ubiquiti. It must be identical.

    Can you double check?

    Shlomi

  • Hi Shlomi,

    I changed the UARTs data reading (using PuTTY now) and have caught the same 3-seconds increased current consumption case, attached below.

    Logs zip: https://drive.google.com/file/d/1rIk13RhCC81UKpnKDZjwA3pt15TrYvzq

    This event occurs 682 seconds after the start.

    The hardware setup remains the same.

    Hopefully, logs content is now consistent and more useful ?

    Kind regards.

  • Hi,

    This one is completely corrupted but I could recover the previous one that occured ~420 seconds from the beginning.

    The log marked as MAC was actually NWP and vice versa.

    Anyway, I could not observe any strange behavior on MAC or NWP.

    Both seem to go to ELP/sleep and wakeup only to receive the beacon and multicasts.

    Also, the value of 10mA seems also strange since if I remember correctly, NWP/MAC would normally consume ~20mA when active.

    Are you probing the current from CC3135 only or does it also include your MCU?

    Shlomi