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.

Set GPIO TM4C123 at reset

Hi everyone,

I'm developing an application for the tiva TM4C123. Certain GPIOs/PWMs are connected to an H bridge in order to control a DC motor. When I reset the board (pressing the RST button on it), or run the debugger in CCS, this GPIOs have values that turn the motor on at full speed.


I would like to be able to set the default values of this GPIOs before the program starts, so that the motor doesn't start in these conditions.


I would also like to know if there is a way to set GPIOs to a certain value when the debugger gets to a breakpoint and the program halts (because the motor keeps running as well when that happens).

Best regards,

Claus

  • Hello Claus,

    There are two ways of achieving this

    1. Add external Pull Up and Pull Downs so that the IOs connected to the external device(s) can remain in an OFF state
    2. Add a Power Switch for the Motor which is OFF by default, so that only when the micro is up and configured will it enable the motor

    Regards
    Amit
  • Beyond Amit's (always) good advice - may I question the "soundness" of any, "Motorized design" which reacts as you describe.

    When (most all) MCUs return from reset - their GPIO's default to high-impedance input state - and it is "YOUR" responsibility to know this - and to provide adequate safeguards!   Most (serious) H-Bridges provide (some) means to guard against such, "Disordered Turn-On."   (the ones my firm uses include internal pull-down resistors - insuring a "known" (and safe) OFF state while the MCU awakens & orders the GPIO/PWM outputs as code directed.)

    In my firm's work w/Medical & Defense - we never/ever enable a motor w/out a strict sequence of, "Checks/Balances" - which insure that the MCU has fully/properly become ready - that power is adequate (& w/in spec) and that all "System Safeties" signal, "Ready to Launch."  Perhaps your system could benefit from (some) of those reasonably (standard) methods?  

    I would suggest - in addition to the installation of, "hard, known, logic levels @ ALL H-Bridge inputs - your addition of a, "Motor-Enable/Launch" switch input.   For maximum safety - we design our motor control SW to seek a specific level "toggle" - upon this "Enable/Launch" input.   (in this manner - inadvertent power turn-on cannot, "Start the motor - because the Enable/Launch switch was left on!!!)   It is (only) the toggle of that switch - after all other checks/balances have been completed - which allows Motor Operation!
     
    As to your debugger issue - vendor's PWM Generators include a clever SW mode (bit w/in a PWM Register) which "disables" the PWM outputs when the debugger halts the program. Have you noted - and implemented - this helpful & critical feature? (appears not)

    MCU manuals are not an especially pleasant, "afternoon's read."   Yet that's where (many) answers to your design reside - I've touched the surface here - care & safety should always be of "High Concern" when any motor is deployed...

  • Let me echo this and provide a cautionary tale.

    For industrial EV motor controllers there is an input commonly called an SRO (or Static Return to Off), colloquially a deadman switch. For a sit down vehicle this would usually be a seat switch to indicate someone was present before allowing the motor to engage. In addition if the SRO disengages (ie you get off the seat), not only do you need to re-engage it you must return the direction lever to neutral and the throttle to zero before the motor is allowed to re-start. Likewise the direction must be in neutral and throttle in zero after power-on before the motor will engage. If you leave the direction selected the motor will not start solely by your act turning on the 'ignition'.

    Now the cautionary tale. This is just a public tale I've collected but shows why you have to pay close attention to all the details.

    catless.ncl.ac.uk/.../21.50.html

    This is from the risks list which is highly recommended reading for anyone involved in embedded computing.

    Robert