Q&A: Why do I sometimes see the Ctimer counter keep at 0 after my Ctimer configuration and start operation?

Full question(s):

Why do I sometimes see the Ctimer counter keep at 0 after my Ctimer configuration and start operation?

Answer(s):

While most of the Ctimer register bits are reset by the generic chip reset, some bits are only cleared by the CLR bit being set. Without a call to am_hal_ctimer_clear() (or the CLR bit being manually set), it is likely that the Ctimer could in some cases be waiting for a trigger to occur before allowing the Ctimer to count. This explains the non-counting sequences that have been observed.

This issue applies to all current Apollo devices (Apollo, Apollo2, Apollo2 Blue, Apollo3 Blue).  A software implementation to address the issue is automatically handled with SDK revision 2.3.0 or later.  However, if working with SDK revision 2.2.0 or earlier, then you should make a call to am_hal_ctimer_clear() before any Ctimer configuration such as am_hal_ctimer_config_single(), am_hal_ctimer_config(), or am_hal_ctimer_config_trigger().

The root cause of the issue is that each ctimer consists of three logic blocks:

• Registers (CTTMRx, CMPRAx, CMPRBx, CTCTRLx, CMPAUXAx, CMPAUXBx, CTAUXx),

• The counter itself (whose value is visible in the CTTMRx register), and

• Control logic that handles enabling the counter, managing counter rollovers and triggers, and generating outputs and interrupts.

              

The root cause is that the general chip reset will reset the counter value and registers, however, it does not reset the control logic block directly. The control logic is reset by the CLR bit in the CTCTRLx register to ensure that all control logic can be directly cleared independently of all the other timers at runtime as the timers are reused. As a result, each CTimer should have the CLR bit set to 1 and then cleared to zero before use of the timer to ensure that all of the associated controls are properly initialized before any operation.

If the CLR bit is not set, then the control logic may be in an indeterminate state after reset. Most of the time, these registers will end up being set to 0 since power has just been applied, however, during soft resets (including brownouts), these registers may take on random values and thus not operate properly without a CLR operation.