CC3200MOD: IO_Park Setting for application-controlled output

Sarah,

Thank you for your quick response. To answer your questions:
1. I am only using LPDS in my application.
2. I have the LED on GPIO28.
3. I am using custom hardware, however I've also got my code build-able to test on Launchpad board. Note that my indication LED is routed to GPIO9 (D7) when building for the Launchpad. I do notice different operation between the two setups, but neither is correct. I'll describe in detail below.
4. For Launchpad build, I've only modified GPIO 9 (D7, set as DONT_CARE) and GPIO22 (SW2, set as WEAK_PULL_UP_STD). For my custom hardware, I've made the same two modifications for launch pad (note button is on GPIO15 and LED is on GPIO28) and additionally I've modified GPIO10, 11, and 16 for NO_PULL_HIZ (to prevent leakage through external pullups), and GPIO9 for WEAK_PULL_UP_STD (controls a FET to my backlight which should be always on). All remaining items in the park struct remain the same.


Here is a bit more detail on my application:
My main loop executes every 100ms and I'll provide test results for three LED states: Normal blink (500ms on, 500ms off), Short blink (100ms on, 900 ms off), and Solid on. Note all cases work when sleep is disabled for both platforms.

Note a key difference between Launchpad and my custom hardware is LED drive. In my hardware, I've got the CC3200 connected directly to LED/resistor (resistor set for 2mA). In Launchpad, there's a FET that controls power. I've noticed the blink rate changes when putting an oscope probe on directly on the GPIO pin with my custom hardware. Oddly, the same doesn't occur on the Launchpad when I probe the FET gate.

Here is what I see:
1. Short Blink (100ms on, 900ms off)
-This works for both Launchpad and custom hardware, perhaps because the 100ms on directly relates to the 100ms sleep time.
2. Normal Blink (500ms on, 500ms off)
-Launchpad: 5ms on every 1s
-Custom hardware: 10ms on every 100ms when probe is not directly on GPIO pin. When directly on GPIO pin, it changes to ~4ms every 1s.
3. Solid On
-Launchpad: Always off
-Custom Hardware: 15ms every 100ms when not directly probing GPIO pin. When directly probing GPIO, it changes to always off.


Any thoughts on what might be happening would be greatly appreciated.
Thank you,
-Jon

Sarah,

I'm looking to see if you have any advice for me?

What is the recommended way to maintain an output through sleep using PMF? Is setting io_park to DONT_CARE the right direction?

Thank you,
-Jon

Hi Jon,

What output are you seeing when using WEAK_PULL_UP_STD, as you stated above? From what I've gathered from testing on the LaunchPad on an unused GPIO pin, it looks like any option, including "weak" pull up, may not be strong enough to power an LED while in LPDS. What I'm seeing is very low, around 0.1 V.

Best regards,
Sarah

Thank you for the feedback Sarah.

I don't believe setting the GPIO to WEAK_PULL_UP_STD makes sense as we're trying to drive it as an output.  I would agree this wouldn't have enough strength to drive an LED.  I am using this on two GPIO's in my application, but neither is meant to drive significant current which is why they work.  I am not sure why your board is not able to drive an unused GPIO high, but I'm not sure we're going in the right direction trying to debug that.

Is there any documentation on the PMF parking, specifically what DONT_CARE is used for?  There must be a way to maintain an output through sleep.

-Jon

Sarah,

Have you tested idle_profile example on your Launchpad? I am experiencing the same behavior with this example app; the connection LED, D7, will turn on very briefly during wakeups and then stay off during sleep. You can see the LED turn on briefly both when timer expires and when SW3 is pressed.

The example application has the LED GPIO pin (GPIO9, pin64) io_park set to pulldown, which doesn't make sense. I've tried putting other values for it, but I cannot get LED to stay solid.

Note I am using Service Pack 1.0.1.6-2.6.0.5 and CC3200 SDK 1.2.0.

Interested to hear if you see the same problem.

-Jon

Sarah, can you test the idle_profile example with your setup to see if connection LED (D7) stays on or not?

Hi Jon,

You agreed above that the GPIO in LPDS does not have a high enough current to drive an LED. So I'm confused, what are you asking?

LPDS was not designed to have functionality such as driving high-current GPIOs, so there does not seem to be a dynamic way to maintain their states. Parking the pin is recommended to avoid leakage currents, and DONT_CARE just does not park the pin. The GPIO output would still be disabled to save power in this mode.

Best regards,
Sarah

Thank you for the response Sarah.

I agree that using internal pullup wouldn't drive an LED, but that sounds like a setting for an input. I was looking for how to keep the GPIO pin as an output. Are you saying it is not possible to drive outputs during LPDS?

-Jon