This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

TIMER1 compare not triggered for CC=0x00

I am using a TIMER1 compare event to generate an interrupt. Generally the code all works fine, but I have noticed some strange behaviour when loading the CC register with 0x00. If the timer is allowed to run freely and overflow, then it is possible to generate a compare event when the timer rolls-over to 0. No problem there. But then I tried to limit the maximum timer count using;

NRF_TIMER1->SHORTS |= TIMER_SHORTS_COMPARE2_CLEAR_Enabled << TIMER_SHORTS_COMPARE2_CLEAR_Pos;
NRF_TIMER1->CC[2] = T1_TICKS_MAX;

My understanding is that this should cause the timer to reset to zero when it hits the value in CC2 (T1_TICKS_MAX). However, when I do this I no longer get any compare events generated for CC=0x00. Any other CC value less than or equal to T1_TICKS_MAX works fine.

This seems a bit unexpected to me. Is this normal behaviour? Or do I perhaps have a bug in my code somewhere?

Parents
  • @RK I think this answers my question, thanks. However, it does leave me with a very awkward edge case that I need to work around.

    I schedule my compare events by looking at the value in the CC register that was used to generate the previous event, and then adding some offset to it. When I add the offset, I need to make it wrap back around if the result exceeds the TIMER limit (using the % operator). Occasionally the final result will be 0. So I now need to decide what to do in these cases.

    I guess I will have to add a check to catch any cases where the CC register would be set to 0, and instead set it 1. This means the timing of my compare events is going to be a bit out in some cases.

Reply
  • @RK I think this answers my question, thanks. However, it does leave me with a very awkward edge case that I need to work around.

    I schedule my compare events by looking at the value in the CC register that was used to generate the previous event, and then adding some offset to it. When I add the offset, I need to make it wrap back around if the result exceeds the TIMER limit (using the % operator). Occasionally the final result will be 0. So I now need to decide what to do in these cases.

    I guess I will have to add a check to catch any cases where the CC register would be set to 0, and instead set it 1. This means the timing of my compare events is going to be a bit out in some cases.

Children
No Data
Related