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.

Tivaware AFSEL HW requires DEN 0x51c ADC analog peripheral selected inputs.

Guru 55913 points

PinMux Utility 1.0.4 will assert DEN call into the saved (pinoutput.h) clearing the GPIO Digital Enable (DEN) bits for the ADC Analog peripheral selected inputs. This DEN function appears to be ok if using the PinMux utility though otherwise falls short to set the DEN bits accordingly.

Appears Tivaware uses GPIOPadConfigSet() to clear the DEN bits register 0:0x51c when setting the pin type as STD such as a PWM output requires, questioning if this is occurring when the GPIO PAD pin type is configured as  ANALOG?

This issue is (gpio.c) function in Stellarisware would automatically set the DEN bits in register 0:0x51C accordingly when ever the GPIO pin DIR mode was being set to HW.  That functionality is perceived to be missing from call GPIODirModeSet() asserted from within GPIOPinTypeADC().

 

  • Hello BP101,

    The Configuration of Analog Functions actually call

        GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA,
                         GPIO_PIN_TYPE_ANALOG);

    with the API parameter GPIO_PIN_TYPE_ANALOG which would clear DEN and set AMSEL bit.

    Once the DEN is cleared and AMSEL bit is set, the Digital functions do not have any control, so setting it as IN, OUT or HW does not have any bearing,

    Regards

    Amit

  • Hi Amit,

    Agree that is where it appears to be clearing DEN bits, not easily to see in debug single stepping through that area. Recall in past Stellarisware (gpio.c) GPIO Analog (ANIx) inputs were considered a (HW) peripheral not SW (IN) pin type, therefore the sub function is set incorrectly as IN for SW control and this post to question why an ANIx peripheral pin is now being set in Tivaware as SW control and not HW hardware control?

    The three analog comparators have GPIO inputs circuitry directly tied to the peripheral, GPIOPinTypeComparator() making a call to GPIOPinDir() required to be set as a SW control using the IN designator (DS page 1777). This is likely why the confusion in this area. Perceivably GPIOPinTypeAnalog() then should be setting (AINx) pins input direction designator as HW not ((IN=(SW)). The HW type designator is synonymous to AFSEL (peripheral owned pin) in Stellarisware was used to detect the need to clear the DEN bits.

    The early release Tivaware migration PDF makes no mention of changing the behavior of (gpio.c) functions in this area of the code along with a multitude of other changes that have been made in (gpio.c) and (pin_mux.h)

  • Hello BP101,

    The changes had been made StellarisWare latest release as well and has no bearing on XM4C129 chip.

    While I agree IN (which is SW mode control) is something which cannot be seen easily during step debug needs to have a stronger reason for usage.

    Regards

    Amit

  • Possibly this was incorrect all along and note worthy the designator (IN) was also being set in Stellarisware (gpio.c). By all accounts it should be set as (HW), the ADC peripheral controls and owns the (ANIx) pin and not the GPIO PAD. By all account this function seemingly violates AFSEL principal even though AMSEL mode is being set at the GPIO PAD. That is what I believe to be the unique difference between SW control or HW control over the GPIO pin.

  • Hello BP101,

    As mentioned earlier, in Analog Mode the SW or HW selector will not be applicable as the DEN is cleared

    Additionally putting it in IN/OUT mode will clear AFSEL disconnecting any PCTL setting as well.

    Regards

    Amit

  • in Analog Mode the SW or HW selector will not be applicable as the DEN is cleared

    Use the GPIOAMSEL register (see page 780) to select analog mode. Signals are configured as GPIOs on reset,

    except for those noted below.

    Your actually saying HW or SW is only valid for digital enabled (DEN) peripheral pins and never analog peripheral pins where the (IN) selector takes precedence. Never knew this fact :)

    That might be good to point out in such area of the data sheet that explain the difference between the two. 

    Thanks for making that more clear. For some reason I was under the belief the (HW) selector implied,  the peripheral pin had control over the GPIO pins rerouted to the peripheral through the PIN MUX and software control over the GPIO port pin was no longer possible.

    IN effect the AMSEL register settings take precedence or over ride the GPIO PIN MUX selector HW, used only with DEN enabled peripheral functions.