• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 789 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

EK-LM4F120XL: Problem: Switching output/input on GPIO

Nelson Lombardo
Prodigy 10 points

Part Number: EK-LM4F120XL

Hello community!
I have a problem switching the type of GPIO from output to input.
I'm working on pin 1 of port D. First, I remove the resistors R9/R10 from PCB.

In my code, enable the peripheral

SysCtlPeripheralEnable(
  SYSCTL_PERIPH_GPIOD
);

Next, configure the pin

GPIOPinTypeGPIOOutputOD(
  GPIO_PORTD_BASE,
  GPIO_PIN_1
);

In some part of my code I change the GPIO type

GPIOPinTypeGPIOInput(
  GPIO_PORTD_BASE,
  GPIO_PIN_1
);

But, I reach the FaultISR in GDB.

My SW tools:

  • OpenOCD v0.10.0
  • Toolchain gcc-arm-none-eabi v5_4-2016q3

Someone can guide me to try the resolve this problem?

Thanks in advance.

  • 0
    TI__Guru*** 133185 points
    Hello Nelson,

    The LM4F LaunchPad has been replaced with the following board: www.ti.com/.../ek-tm4c123gxl

    Please switch platforms to this LaunchPad and then use our latest TivaWave and then try to implement your application again.

    Also if you have issues on the TM4C platform with TivaWare, be sure to include full source code in future posts.
  • 0
    Guru 117855 points

    Firm/I have that same (very early) board - ours (though limited - No PWM Gens w/in that past MCU) works fine!

    While your board's silk-screen may read LM4F - the MCU is (clearly) marked LX4F!

    Note: Any LX4F (there were NO/ZERO LM4Fs produced!) is spec'ed to work under StellarisWare - NOT newer RebrandWare!    (the newer, pin_map.h file, fails to accommodate LX/LM devices!)   Use StellarisWare 9453...    Your using "OpenOCD" culls you FAR from the herd - makes assistance far more difficult.

    Might you follow this sequence - then repeat your code run?

    • After "SysCtlPeripheralEnable()" add a delay and/or test for the peripheral being "ready."
    • Eliminate (temporarily) your "change of "GPIO Type."    (i.e. choose just one - do not change.)    
    • Then RUN the code - do you arrive (again) w/in (dreaded) Fault_ISR?
    • If successful - change the "GPIO Type" to the other config.   Run the code.   Note results.
    • If both (individual RUNS) of "one unchanged GPIO Type" succeed - then it proves unlikely that such "change of GPIO Type" proves the culprit.
    • As the (mistakenly, banned here) "KISS" so well  teaches - reduce your code to the bare minimum - at some point your code is (likely) to "escape" Fault_ISR!      This - most always - enables your discovery of the "issue's cause."  Clearly it is NOT the change of GPIO Type!

    While (always) unstated - I suspect that you (may) be attempting "One Wire" Commo - thus the need to switch GPIO from "Input to Output."    This has been achieved OFTEN - there is NO NEED to change your board!