TM4C1290NCZAD: (Again)Unexpected program halt caused by timer counter update

Hi O.H

Q1: If the timer counter value is updated without stopping the timer, what kinds of malfunction or unexpected behavior could occur?

Updating the timer load value on the fly without suspending the peripheral can trigger several critical faults due to how the General-Purpose Timer Module (GPTM) hardware registers synchronize:
1Severe CPU and JTAG Starvation (Root Cause of Lockup)

• The Mechanism: If TimerLoadSet() updates the target register near the exact moment the hardware counter transitions, it can create an invalid internal state or immediate underflow.
• The Consequence: The timer hardware may flag a continuous, un-clearable timeout interrupt or enter an ultra-high frequency interrupt cycle.
• System Lockup: Because the timer interrupt has a higher priority or keeps pending instantly, the Cortex-M4 core spends 100% of its cycles servicing the ISR. It starves background tasks and entirely drops the JTAG debug access port (DAP) communication line, throwing Error -2062. refer to: https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

2. Missed Timeouts or Extreme Step Delays
• The Mechanism: By default, the TM4C129x operates with immediate reload updates. If the current counter value is 0x00000005, and the program writes a new value like 0x0000FFFF to the register, the counter resets mid-cycle.
• The Consequence: Conversely, if the current counter value has already passed a point relative to the new configuration, the hardware can miss its comparison or timeout match entirely. In a down-counter, it might force the module to count all the way through a full 32-bit integer rollover cycle (0xFFFFFFFF), stalling your stepper motor's next pulse for millions of clock cycles. Refer to: TM4C129x Timer operation 

3. Stepper Motor Acceleration Jitter
• The Mechanism: Modifying a running counter destroys the precision of the current step profile.
• The Consequence: Steps will either be abruptly truncated (producing a harsh, violent snap in the motor) or stretched excessively, distorting the acceleration and deceleration curve. Refer to: TM4C129x Timer operation

Q2: From a design and specification point of view, is the above workaround of stopping and restarting the timer an appropriate solution?

Yes, the implemented workaround is perfectly appropriate, robust, and highly recommended from a design and specification standpoint.

Refer to: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/414478/tm4c129-timer-capture-with-ti_rtos

Why This Solution Is Correct
• Guaranteed Determinism: Calling TimerDisable() completely freezes the peripheral's internal digital logic state machine. This eliminates hardware race conditions between the CPU writing to the configuration registers and the timer counting down.
• Glitch-Free Motor Profiles: By disabling the timer, updating the exact reload interval, and enabling it again, you ensure every single step pulse matches the intended math calculation. Refer to: TM4C129x Timer operation 

Thanks!