• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 33 subscribers
  • Views 2945 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123GH6PM: Possible to "Unconfigure" a pin using TivaWare?

twelve12pm
Genius 4455 points
Part Number: TM4C123GH6PM


I have several "modes" of operation. One mode requires PB5 to be T1CCP1 and output a 1 ms pulse with 1/10th pulse width. Another mode requires PB5 to be a GPIO input. There could be three or four different modes of operation, each using the pin in different ways. My code includes a finite state machine mechanism to do Setup, Operation, and Tear Down of each mode.

When entering the mode that uses PB5 as T1CCP1, the Setup code does this:

// Set GPIO mux to Timer
GPIOPinConfigure(GPIO_PB5_T1CCP1);

// Set pin type to CCP
GPIOPinTypeTimer(GPIO_PORTB_BASE, GPIO_PIN_5);

// Configure timer as 16-bit periodic
TimerConfigure(TIMER1_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_B_PWM);

// Set PWM period
TimerLoadSet(TIMER1_BASE, TIMER_B, 40000);

// Set pulse width
TimerMatchSet(TIMER1_BASE, TIMER_B, 4000);

// Enable Timer
TimerEnable(TIMER1_BASE, TIMER_B);

This works. Now I'm trying to do the Tear Down code to put the pin back into its original state before calling the Setup code of a different mode. So far, I have only this:

// Disable Timer
TimerDisable(TIMER1_BASE, TIMER_B);

// Set pin type to GPIO
GPIOPinTypeGPIOInput(GPIO_PORTB_BASE, GPIO_PIN_5);

I need the equivalent of a TimerUnconfigure() to tear down the timer setup and GPIOPinConfigure(GPIO_PB5_GPIO) to un-mux the pin from the timer. But there is no function TimerUnconfigure() or equivalent, and there is no GPIO_PB5_GPIO or equivalent define that can be passed to GPIOPinConfigure() to reverse the action of GPIOPinConfigure(GPIO_PB5_T1CCP1).

How can I go about tearing down this setup so that each mode can be entered and exited numerous times, and leave the pin in a consistent state after tear down, without requiring a complete system reset?

  • 0
    Guru 10570 points
    Just re-configure to a different state. If that state is needed to be the same as the default configure it to that.

    Robert
  • 0 in reply to Robert Adsett72
    Guru 117855 points

    Might I offer a different "line of thought?"     Consider the circuitry, "receiving GPIO_PB5" - most likely such (attached) circuitry "expects" 2 signal levels - and alters its response in accordance.     Thus - it proves necessary to (in my mind) "Break the attachment of PB5 to those circuit elements - not currently selected!"     Such can be done via a Data Multiplexer (poster Robert has often suggested such.)

    You must - possibly via pull-up/down resistors - insure that those circuit elements which become "untied" to PB5 - operate correctly when PB5 is divorced!     (again - usually pull up/down Rs will achieve that...)

    Again - it is my (practiced) belief that - "ISOLATION between your different circuit elements" must be considered.    (and very likely employed - thus he addition of Data Mux.)

    To bring about PB5's "Change of heart:"

    • order PB5 to the desired state (likely idle) for that circuit element (about) to be "disconnected from PB5"
    • switch the Data Mux to a "spare (unused) channel!"
    • re-issue the GPIOPinConfigure() as required by the "About to be selected" circuitry.
    • only then - command the Data Mux to switch to the intended (new) PB5 recipient.     (such should be "reasonably" glitch free. - Note the use of the "excess Mux channel" which prevents PB5's "transitory output" from reaching (any) of the target circuits - until (after) properly configured!)

    Your Data Mux might have to be "comfortable with & accommodating" to (both) analog & digital signals - such was not presented (or my speed-read missed...)

  • 0 in reply to Robert Adsett72
    Genius 4455 points
    That's exactly what I want to do -- but how?

    What will reverse the effects of GPIOPinConfigure(GPIO_PB5_T1CCP1)?

    pin_map.h defines the following for PB5:

    #define GPIO_PB5_SSI2FSS 0x00011402
    #define GPIO_PB5_M0PWM3 0x00011404
    #define GPIO_PB5_T1CCP1 0x00011407
    #define GPIO_PB5_CAN0TX 0x00011408

    I want "None of the above" and there's no option for that.

    How do I do GPIOPinConfigure(GPIO_PB5_NONE_OF_THE_ABOVE) to un-set the mux???
  • 0 in reply to cb1_mobile
    Genius 4455 points
    @cb1_mobile Thanks for your reply. However hardware is not the issue at this time. The board is designed. The circuit is correct. This application is for something we've been doing since 2012 using another vendor's microcontroller. We're doing it with TM4C now. I am trying to avoid direct register programming because we are using several TM4C part numbers for similar purposes, we're writing one software codebase to support all the hardware variants, future hardware variants will be added, and therefore we're writing for maintainability. In this application, the hardware gets built once but the software must be maintained, improved, and expanded for many years. (I recently saw a whitepaper I can't seem to locate now that talked about the need to maintain software for decades, let alone years.)

    With my current question, I know that TimerDisable(TIMER1_BASE, TIMER_B) will "undo" TimerEnable(TIMER1_BASE, TIMER_B), and the timer can stay there, configured but not running. GPIOPinTypeGPIOInput(GPIO_PORTB_BASE, GPIO_PIN_5) will set the pin direction back to input. My only remaining question is, what TivaWare incantation will "undo" GPIOPinConfigure(GPIO_PB5_T1CCP1) to un-mux the GPIO pin from the timer? Because that doesn't seem to be an option.
  • 0 in reply to twelve12pm
    Guru 10570 points
    Does not configuring them as GPIO undo the mux? I would have expected it to but then I don't toggle between modes (not sure why that would be useful).

    Robert
  • 0 in reply to Robert Adsett72
    Genius 4455 points
    GPIOPinTypeGPIOInput() does this:
    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);
    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    It does not touch GPIOPCTL as far as I can tell.
  • 0 in reply to twelve12pm
    Guru 117855 points
    I don't believe that you post fully explained the "circuitry downstream from - and connected to PB5."

    Might it be that only ONE set of circuitry is deployed - per board? If such is "Not the case" - then "All of the multiple circuits will "see & feel" the effect of PB5" - that cannot be your intent - can it? Kindly detail - we remain unclear...
  • 0 in reply to cb1_mobile
    Genius 4455 points
    I did not explain the downstream circuitry because it's irrelevant. I'm asking about software. I can't seem to figure out what TivaWare function to call. I've been doing things like this on TI's competitor's MCUs for years. I know it can be done.
  • 0 in reply to twelve12pm
    Guru 117855 points

    twelve12pm said:
    I did not explain the downstream circuitry because it's irrelevant.

    Should multiple (different) circuits "all attach to PB5" - then each/every one will be impacted by PB5's level or edges - and I continue in the belief that such is (very) relevant.

  • 0 in reply to twelve12pm
    TI__Guru*** 135355 points

    Hello twelve12pm,

    If you overview the TivaWare Driver Library Guide you will find there is indeed no function to 'undo' the mux configuration: www.ti.com/.../spmu298d.pdf

    The reason for this is such a function would be an unnecessary step.

    For example, you have correctly started the following about TivaWare:

    twelve12pm said:
    GPIOPinTypeGPIOInput() does this:
    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN);
    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD);

    If you delve further into these calls, specifically the GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_IN); call you will find the following:

        HWREG(ui32Port + GPIO_O_AFSEL) = ((ui32PinIO & 2) ?
                                      (HWREG(ui32Port + GPIO_O_AFSEL) |
                                       ui8Pins) :
                                      (HWREG(ui32Port + GPIO_O_AFSEL) &
                                       ~(ui8Pins)));

    This function call for a direct register write is to configure the GPIO Alternate Function Select (GPIOAFSEL) for the TM4C123GH6PM.

    By doing this, the GPIO Alternate Function Select will be turned to a mode where the pin is treated as a GPIO and it is controlled by GPIO Registers. Therefore this renders the specific setting inside of GPIOPCTL irrelevant as the pin is no longer configured to use any of peripherals determined by GPIOPCTL.

  • 0 in reply to Ralph Jacobi
    Genius 4455 points
    Thank you for your very good explanation. Your help is very much appreciated.