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.

CC3235MODASF: Confirmation Device is Fully In Hibernate Mode - Measuring High Current on Some Units

Part Number: CC3235MODASF

Tool/software:

We have experience with CC3220MODASF and have no issues with reaching low hibernate current in production units.  Each unit is specifically tested in production to confirm.  

We have designed a new product with CC3235MODASF and has very few components besides the module itself.  On about half of our recent prototype run the unit hibernate state current is over 200uA.  On the other units it's 10uA or less as expected.  When we apply some heat to the WiFi module while in hibernate mode the current fluctuates on a 'high current' unit, while on the units with current in the expected range it remains very stable.  We are thinking its possible on these high current units the CC3235 is not fully entering hibernate or some aspect of it is not in the correct state.  In our testing we are using the same firmware build for the measurements.

Is there something we need to to additionally for the CC3235 when entering hibernate that was not needed on the CC3220?  I have re-reviewed the design checklists and other documentation and I can't really find anything different.  Is there a way we can pop the shield off the module and check state of signals inside to confirm it is in hibernate or not? 

Pete 

  • Hi,

    We would need more information to figure out this issue.

    Could you tell us what version of the SDK, and service pack you are using. How are you measuring the current current consumption? 

    BR,

    Jessica

  • Jessica,

    I'm working with Pete on this problem. We're using SDK 6.10.0.05, and Service Pack sp_4.11.0.0_3.7.0.1_3.1.0.26.bin.

    We measure current by driving a 3VDC voltage into the board through a benchtop ammeter with a 200uA or 20mA range. Boards with the expected hibernation current measure <10uA as expected, boards with elevated hibernate current outrange the 200uA setting and measure 1.0 - 1.5mA on the 20mA range setting.

  • Hi,

    How looks power consumption of both boards (good, bad) at reset state? It is same or is different? If will be different, it will be probably some static leakage (e.g. issue with re-flow under module).

    Do you have connected some other device to the module (e.g. computer connected via UART) during your measurement? If so, this can significantly affect measurement (e.g. parasitic powering via protection ESD diodes at pins).

    What is parked state of unused pins? Are pins set to GPIO input? Because in this case it may to be a "classic" problem of low power MCUs when Schmitt trigger is oscillating due to NC input causing increased current consumption.

    Jan

  • Jan,

    The park state for the pins is the default settings. Does this mean the all unused, pins should be defined in the syscfg files as inputs?  

  • Hi,

    Unused pins should NOT be set as input. This is same for all low power MCUs, regardless their manufacturer. By default are pins at CC3235 set into Hi-Z and this should be safe.

    Jan

  • All measurements have been been taken without a programming pod or any other external device connected to the module.

    Driving the RESET pin low on the device increases the current draw by ~30uA for both a good and a bad board. A good board goes from 8uA current to 41uA, the bad board I have goes from 250uA to 280uA.

    If this is static leakage due to reflow, that would be a huge problem because nearly half of our boards fail to meet our hibernate current spec. Is there some way we can improve the layout to reduce this fallout?

  • Hi,

    It looks like a static leakage abound 230uA-240uA at your faulty board. At first step you should validate that you have populated right  components at your boards (sometimes it may to happen that company which is doing assembly accidentally exchange component values).

    My personal tip is that issue is under module, but culprit may to be even other component. Similar behaviour can have broken multilayer capacitor, not properly done reflow under other SMD components (resistors, capacitors) or even I seen leakage via wrongly manufactured PCB.

    Maybe you can check your module assembly at X-ray. But I will expect that you will not see anything, because it does not look like direct short. It looks like some kind of contamination or reflow issue. Maybe you can try re-heat your module by hot air.

    If PCB layout is done according TI recommendation, than I expect this will be fine. But I am not sure if this can be improved somehow. It is hard to provide advices at similar case.

    Jan