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.

GPTM down count CCPn edge count mode with TnMATCHR interrupt disables timer but leaves TnV/TnR counting down to load value TnILR.

Guru 55913 points
Other Parts Discussed in Thread: LM3S8971

GPTM down count edge count mode with TnMATCHR interrupt disables timer but leaves TnV, TnR counting down to reload value in TnILR. Timer timeout then reloads TnILR however timer gets exponentially slower when doubling values TnILR even when TnMATCHR is far smaller value. Seemingly the intend job for up count mode which has documented errata.

The TnILR value need be the maximum allowable edges counted in down count mode, not the reload value when TnMATCHR is configured mode of GPTM. Even reloading TnILR with value of (TnMATCHR + 1 or more) in interrupt works for one cycle then looses monotonic count order and seemingly locks up timer.

Datasheet text suggests the timer should stop on TnMATCHR but does not restart counting from the TnMATCHR downward on next cycle rather timer down counts from the larger TnILR value.

13.3.3.3: After the match value is reached in down-count mode, the counter is then reloaded using the value in GPTMTnILR and GPTMTnPR registers, and stopped because the GPTM automatically clears the TnEN bit in the GPTMCTL register. Once the event count has been reached, all further events are ignored until TnEN is re-enabled by software.

How to reset/reload GPTM from smaller values (TnMATCHR) starting next timer cycle CCP input edge count and still allow maximum greater value loaded TnILR? 

  • As you write often of LM3S8971 and TM4C - might your identification of the (suspected) offending device warrant inclusion?
  • Not in this case --- LM3S post mortem analysis has left the building fir good!

    Discovered GPTM input edge count interrupt behaves oddly if TnILR is not set near 2 times above any later update to TnMATCHR being derived TnBV subtracted TnILR near 1 second later. The lower edged count TnMATCHR 1 second interval interrupts are set for 423/EPS with a maximum TnILR 960/EPS. Much better now and far less NVIC interrupting than 1 second intervals occurring 2/EPS in TnMATCHR events.

    Appears GPTM edge count does after all allow TnILR a maximum count constraint. However TnBV/TnBR continues counting down from where it was last stopped by the match count interrupt event and does not reload TnILR until timer timeout. Or at least that is what CCS debug shows occurring.

    CCS debug does not show all the GPTM internal counter parts or digital reports of them and makes it difficult to model interrupt driven procedure handlers not seeing the full counting chain in action.