Part Number: MSP430G2955
- We are using time 1 TA1R with continuous mode for generating system ticks. Every time timer overflow interrupt occurs, we will increment a counter in firmware to track the upper 16 bit tick in the interrupt context
- In order to read TA1R properly, per TI recommendation, we need to stop timer (set TA1CTL to stop mode), read TA1R and the counter (<< 16 bit to form 32 bit tick), then restart timer to continuous mode
- We thought this is 100% race condition free, however, during local testing, I have seen evidence in rare occasions that once we stop timer, TA1R has rolled over to 0x0000 from 0xFFFF, but the timer overflow interrupt hasn't occurred, so the tick becomes backwards in time.
- For example, current tick is 0x0001 FFFF, where TA1R is 0xFFFF and upper 16-bit counter is 0x0001. When this race condition occurs, the next tick we read could be 0x0001 0000 instead of 0x0002 0000
- I have seen evidence with debugger loading debug image to trap it and also one unit without debugger that indicates the race condition occurs from system logging.
- Is this race condition expected from timer overflow interrupt? Meaning TA1R can roll over at overflow without overflow interrupt already triggered and interrupted MSP430?
