The 8-bit PIC family (I'm working with pic18f46k22) offers some timers (timers1/3/5) that can work in both asynchronous and synchronous modes when clocked from an external source.

The obvious differences are:

  1. asynchronous operation gives the possibility for timer to run in sleep mode
  2. An asynchronous source can clock the timer faster since it is independent on the system clock (table 27-12): timing specifications

and as for the advantages for synchronizing the external clock source... well, I can't see any. One disadvantage to think of is the possible corruption of data if the CPU tries to read the counter while it is incrementing, but the datasheet states:

12.5.1 READING AND WRITING TIMER1/3/5 IN ASYNCHRONOUS COUNTER MODE: Reading TMRxH or TMRxL while the timer is running from an external asynchronous clock will ensure a valid read (taken care of in hardware).

Can someone please explain why did they add the possibility to synchronize the external clock source with the internal phase clocks? I feel that I'm missing something. Thanx a lot


Some operations on the timer don't work when it might change in the middle of a cycle. This timer is used in conjunction with CCP modules too. Read the datasheet section on the CCP modules and you will probably find restrictions of when it must be run in synchronous mode.

For example, compare to a particular value can be flaky if the timer value might change in the middle of the compare operation, or might increment past the compare point between checks.

  • \$\begingroup\$ That may explains a lot: 14.1.2 TIMER1 MODE RESOURCE The 16-bit Timer resource must be running in Timer mode or Synchronized Counter mode for the CCP module to use the capture feature. In Asynchronous Counter mode, the capture operation may not work. This is probably one reason for adding the synchronization option \$\endgroup\$ – fhlb Mar 23 '16 at 16:55

If you need a timer to operate in sleep mode, it must be set in asynchronous mode, and if the timer is set in asynchronous mode any change to change its state under processor control (including switching between synchronous and asynchronous mode) which occurs at the same time as an incoming pulse may cause its state to be corrupted in arbitrary fashion.

If you have two async-capable timers, I would suggest that you configure one of them to run continuously and never do anything with it except read its value. Such reads should be performed by reading the low byte, then the high byte, and then the low byte again. If the low byte changed between the two reads, repeat the process. The other timer may be configured for wake-up events, but with a few caveats:

  1. Write the low byte of the timer before doing anything else to change it and read it afterward. If the low byte has changed, assume that the timer might have been arbitrarily corrupted and start again from scratch.

  2. On at lest some parts, the timer interrupt occurs on the clock edge after a clock edge that advances the timer from 0xFFFE to 0xFFFF. Programming the timer with a value of 0xFFFF will not cause an interrupt on the first tick following such action, but rather on the 65,537th tick. I don't know if there's a way to set the timer to get an interrupt on the next tick.

Using these techniques together, it's possible to logically combine the two async-capable timers to yield the functionality that would be available on a timer with an asynchronous-compare facility.

  • \$\begingroup\$ Hi, I was waiting for you to answer as I read your post on a similar issue... I actually have no design issue and I was only setting the timer to work as an edge counter. But I kinda hanged on the synchronization option... My question was that I can't figure why is there an option to synchronize the external clock source if the asynchronous operation is obviously more advantageous \$\endgroup\$ – fhlb Mar 23 '16 at 17:02
  • \$\begingroup\$ the microcontroller also has the feature to buffer the high byte when reading the low byte and I can't figure out why shouldn't I use this mode. It should solve the issue you pointed to and always return a good read. the same is correct for writes as the buffered value of the high byte is written when the low byte is written to and hence guarantee a good write \$\endgroup\$ – fhlb Mar 23 '16 at 17:06
  • 1
    \$\begingroup\$ @fhlb: If the timer is in asynchronous mode, one must read the lower byte twice even if one doesn't care about the upper byte, and would have to read the upper byte twice if one never looked at the lower byte. If one reads a byte at the exact moment it changes from 0x7F to 0x80, or from 0xFF to 0x00, it could report any value, and the upper-byte latch does nothing to avoid that issue. If two reads yield the same value and it's not possible that the counter has incremented a multiple of 256 times between the reads, the value is guaranteed correct, but two reads are definitely required. \$\endgroup\$ – supercat Mar 23 '16 at 17:15
  • \$\begingroup\$ I understand that reading an asynchronous counter may pose the risks you pointed to, but the datasheet clearly states that a valid read is always insured, and that the problem is when the timer overflows between the read of the lower byte and the read of the higher byte. I'm not that clocked electronics guru and I can't tell how is that possible but shouldn't we trust the datasheet? \$\endgroup\$ – fhlb Mar 23 '16 at 17:34
  • \$\begingroup\$ 12.5.1 READING AND WRITING TIMER1/3/5 IN ASYNCHRONOUS COUNTER MODE: Reading TMRxH or TMRxL while the timer is running from an external asynchronous clock will ensure a valid read (taken care of in hardware). However, the user should keep in mind that reading the 16-bit timer in two 8-bit values itself, poses certain problems, since the timer may overflow between the reads. \$\endgroup\$ – fhlb Mar 23 '16 at 17:39

supercat mentioned reading microchip erratas... look at the PIC18(L)F26/46K22 Rev. A2/A4 Silicon Errata and Data Sheet Clarification(this microcontroller you're using):

  1. Module: Timer1/3/5

When Timer1, Timer3 or Timer5 is operated in Asynchronous External Input mode, unexpected interrupt flag generation may occur if an external clock edge arrives too soon following a firmware write to the TMRxH:TMRxL registers. An unexpected interrupt flag event may also occur when enabling the module or switching from Synchronous to Asynchronous mode.

Work around:

This issue only applies when operating the timer in Asynchronous mode. Whenever possible, operate the timer module in Synchronous mode to avoid spurious timer interrupts.

A quick search on google also shows other issues with the asynchronous timer mode with other microcontrollers (example: pic18f4550 errata- fail of the buffered read mechanism and the pic18f97j60 family errata) so its probably a good point not to trust the asynchronous timer too much and add the extra two line of code to verify any read/write. and don't forget the sample code provided in the errata to clear the unexpected interrupt flag generation upon a timer write


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.