Overflow for quad timers is broken (NXP ERRATA: ERR050194)

[jmarsh]

This is just a warning in case anyone runs into the same brick wall that I just did, to save them spending hours tearing hair out. Possibly it is already known by some of the forum regulars but I think it could do with some greater visibility.

The overflow interrupt for quad timers on the Teensy4 (TMR0,TMR1,TMR2,TMR3) does not work when counting upwards. It won't trigger at all, and if the output mode is 6 (set output on compare, clear on overflow) the output signal will not clear.
The counter value for the timer will wrap around to zero with no indication at all that it has happened.

If you search the web for ERR050194 you will find NXP's chip errata documents revealing that this problem exists for basically the entire i.MX RT range of processors.

 

[luni]

Thanks for that!

I think it could do with some greater visibility.

Would be good to have such errata at the datasheet/manual section of the web page

 

[PaulStoffregen]

I've added the errata PDFs for rev B and rev A silicon to Teensy 4.0 and Teensy 4.1 pages.

https://www.pjrc.com/store/teensy40.html#tech

https://www.pjrc.com/store/teensy41.html#tech

Both pages mention when that model made the switch from rev A to rev B chips.

 

[joepasquariello]

Regarding QTMR issue, it's worth noting the errata provides a work-around.

ERR050194: QTMR: Overflow flag and related interrupt cannot be generated when the
timer is configured as upward count mode

Description:

1.Overflow flag and related interrupt cannot be generated successfully in upward count mode.

2.When TMR_CTRL[OUTMODE] is set to 110b, OFLAG output is not cleared on counter
rollover when the timer counts upward.

Workaround:

For item 1, using compare interrupt instead of overflow interrupt by setting compare value to
0xFFFF. The compare interrupt has the same timing effect as overflow interrupt in this way.

For item 2, there is no workaround.

 

[jmarsh]

Yeah but that's not really helpful when I'm already using the compare function for something else. A better workaround is to run the counter in down mode and XOR all values read/written from the counter registers with 0xFFFF - no loss of function, just need to keep track of things well.

 

[jmarsh]

Does anyone have any insight into how any of the MSTR and EEOF flags (in the SCTRL register) and the COINIT flag (in the CTRL register) are meant to be used? The documentation is extremely sparse and of course they aren't used in any of the application specific examples.

 

[manitou]

This is just a warning in case anyone runs into the same brick wall that I just did, to save them spending hours tearing hair out. Possibly it is already known by some of the forum regulars but I think it could do with some greater visibility.

Yep, "known by some" -- During Teensy 4 beta tests (2019) I encountered the problem and found NXP forum discussions that pointed to the errata, see
https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=199536&viewfull=1#post199536

 

[manitou]

Does anyone have any insight into how any of the MSTR and EEOF flags (in the SCTRL register) and the COINIT flag (in the CTRL register) are meant to be used? The documentation is extremely sparse and of course they aren't used in any of the application specific examples.

You might examine the NXP SDK source and examples ....

   Capture_Mode=0,MSTR=0,EEOF=0,VAL=0,FORCE=0,OPS=0,OEN=0 */
./boards/evkmimxrt1060/demo_apps/mc_pmsm/mcdrv_evkmimxrt1060.c
        (TMR_SCTRL_EEOF(config->enableExternalForce) | TMR_SCTRL_MSTR(config->enableMasterMode));
./devices/MIMXRT1062/drivers/fsl_qtmr.c

or query the NXP forums.

 

[jmarsh]

I couldn't find anything in any SDK that actually used them, which doesn't shed any light on how they are intended to function.