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.

Ti-RTOS example UDPEcho: GPIO/I2C/PWM/System Console conflicts

Other Parts Discussed in Thread: CC3200

Hi,

Making good progress using 'UDPEchoCC3X00' as my template and adapting for my application however having issues with some conflicts particularly using the LP LEDs and the System Console.

In the 'Board.h' file there is the comment:

/*
* CC3200_LAUNCHXL_LED_D5 and CC3200_LAUNCHXL_LED_D6 are shared with the I2C
* and PWM peripherals. In order for those examples to work, these LEDs are
* taken out of gpioPinCOnfig[]
*/

This is further reflected in the 'CC3200_LAUNCHXL' files.

Also in the 

'TI-RTOS 2.16 for CC32xx SimpleLink™
Wireless MCUs
Getting Started Guide'

it states in Section 3.4:

— PWM. The PWM driver uses the onboard LEDs D5 (PIN 02) and D6 (PIN 01). While these pins
coincide with GPIO driver pins, they are configured for the PWM driver for the PWM examples.
The GPIO driver APIs should not be used.

However in the UDPEcho readme.txt file this example is also using Board_LED1 which is D6 above (clearly using GPIO mode) ???

While I'd like to use all LEDs in my application I understand you can't use the same pin for separate things at the same time so I'm content to just use Board_LED0 (D0) and the System Console to help me run and debug my application. Problem is I also see conflict on D0 whenever the system console writes a message. I know this as I set up a highest priority clock (8KHz using clock module) and the ISR calls GPIO_toggle(Board_LED0) and I see the clock corrupted (scope probe on P3.9 on LP) when outputing to the system console. Also if I stop output to the system console then the clock is completely clean and uncorrupted.

Can someone clarify the interactions going on here:

- What signals does the System Console use and how do they conflict with LP LEDs/other ?

- what signals do the I2C/PWM examples use (I think I know but be good to restate)

Any other guidelines most welcome.

best regards,

Stuart

Edinburgh. UK.

 

  • Hi Stuart,

    Just a quick reply to say I will consult with an expert on the issue to get back, but it will likely take a few days since it is holiday in the US.

    Best regards,
    Murat
  • Hi Stuart,

    Still investigating the issue, but looks like we don't have enough understanding of the issue and it would help if you could share the relevant code with your modifications?

    Best regards,

    Murat

  • Hi Murat,

    Thanks for coming back.

    I don't believe my code will help (I've moved from run time to the static configurator, added a clock module and have new tasks running also) but likely just add confusion to something that's really (hopefully) quite straightforward.


    My questions all relate to the standard TI-RTOS UDPEcho example you provide:

    1. - What signals does the System Console use and (how) do they conflict with LP LEDs/other ?
    (Any explanation of how System Console works with the CC3200 LP welcome, I must have missed it)

    2. Which LEDs can I use that aren't specified for another use (see my explanation above).

    As I say let's better just to stick with UDPEcho as the basis for this enquiry.

    thks & rgds,

    Stuart
    Edinburgh. UK.
  • Hi Stuart,

    Looking at the schematics and your initial post regarding the LED0/D0, it looks like the System Console is using  a dedicated LED, and there is no mentioning of D0 or the LED0. So, you would need another LED to control, and as D5/D6 (GPIO 10 & 11) are taken your best bet is the Red LED (D7/GPIO_09), looking at page 14 of

    which is the second link on the LAUNCHXL page:

    1.   CC3200 SimpleLink Wi-Fi Wireless MCU Launch Pad Board Design Files (Rev. B) (ZIP 3832 KB)  ()

     2.  CC3200 SimpleLink Wi-Fi and IoT Solution w/ MCU LaunchPad Hardware User's Guide (Rev. B) (PDF 1691 KB) ()

    By the way, looking at the hardware schematics in the zip file following first link, there is no mention of D0, so that path is off limits.

    Hope this helps,

    Murat

  • Hi Murat,

    Many thanks.

    I'm just back in the office and will come back to you once I study your reply.

    kind regards,

    Stuart

  • Thanks, and good luck, and pls post your findings.
    Cheers, Murat
  • Hi Murat,

    Apologies for the delay, I'm back in the saddle now !

    Murat wrote: 'it looks like the System Console is using a dedicated LED'
    ... not sure if you are asking me or telling me this ?

    Murat wrote: 'By the way, looking at the hardware schematics in the zip file following first link, there is no mention of D0, so that path is off limits.'
    ... not sure what D0 is and why it's mentioned ?

    I've read through the recommended literature.
    In a nutshell I would just like to understand how system console output works. Many of the examples use System_printf() followed by System_flush as shown below:

    System_printf("Starting the example\nSystem provider is set to SysMin. "
    "Halt the target to view any SysMin contents in ROV.\n");

    /* SysMin will only print to the console when you call flush or exit */
    System_flush();

    How is this communicated from the CC3200 to the CCS console on the PC. Does it use some I2C output from the CC3200 and if so which pins specifically ? Then it must somehow send via USB to the PC which I'm less concerned about.

    Understanding what pins are impacted (if any) with System Console printf statements will ensure I don't use them for other purposes.
    Apologies if I'm missing something obvious, its just that the penny hasn't dropped yet.

    thanks & regards,

    Stuart
  • Hi Stuart,

    My limited understanding of how this all works is that the System_printf() calls appends the bytes it is printing to an internal buffer, and subsequent System_flush() calls HostWrite function which acts as a sync point btw CCS and the device. CCS programs the on chip emulator to setup a breakpoint in HostWrite and scoops up the print buffer and displays it on CCS debug console. I don't think there is any I2C involvement here, and can't really tell why you would see the LED0 blinking you observe. The CCS emulation logic halts the target so maybe some interference related to this?

    Also curious if you tried using standard printf instead of System_printf and observing the same behavior?

    Finally in reference to your last post, I was just trying to see why you mentioned D0 in your original post and trying to make some guesses. You can ignore if that was more confusing.

    best regards,
    Murat
  • Hi Murat,

    Apologies for the delay.

    Thanks for your answer and support. I'm improving my understanding and I'm happy to close this one off now.

    b rgds,

    Stuart