42BS wrote:
> did you try what happens if OVW is not set using the PMR-rewrite ?
My test code may look as if OVR is set when it is running, but it isn't:
/* Program all pits to 500us timeout, 4 different dividers */
MCF_PIT0_PCSR = MCF_PIT_PCSR_OVW;
...
MCF_PIT0_PMR = (40000 - 1);
...
nPcsr = MCF_PIT_PCSR_HALTED | MCF_PIT_PCSR_PIF
| CF_PIT_PCSR_RLD | MCF_PIT_PCSR_EN;
/* Enable them all, staggered at 1us */
MCF_PIT0_PCSR = nPcsr | MCF_PIT_PCSR_PRE(0);I only set OVW in order to force the PMR into the counter. In all other test code using "nPcsr", OVW is not set.
It makes perfect sense for the Prescaler to be reset when the PMR is loaded with OVW set.
It makes no sense at all for this to happen with OVW clear. The chip does it anyway.
If anyone has code that "ping-pongs" two different values into the PMR in order to either fine-tune the period or to have alternating Short and Long periods, they'll be resetting the prescaler when doing this.
WARNING ON WRITING PMR DURING PIT INITIALISATION
I'm guessing a lot of pregrammers don't know that when they first set up the PIT they MUST OVW, write PMR then (optionally) clear OVW. If they do this the counter will then start from the PMR value. If they don't it will run from 0xFFFF the first time. This would make the first timeout a lot longer than expected - up to 26 SECONDS on an 80MHz clock if using a prescaler of 32768. This is not mentioned in the Reference Manual, but is noted in AN3400 for the MCF5213:
5 Configuration NotesThe following details are important when configuring the PIT:
...
• The order of the initialization process is important if a
desired modulus value is needed. First, configure the PCSR
and set the overwrite (OVW) bit. Then, write the PMR.
This causes the PCNTR to load the PMR value to the PCNTR.
I've tracked PIT documentation back to the MMC2107 Reference Manual. It is word-for-word identical with the MCF5329 manual. Unusual word patterns like "loading of a new value into the counter also reset" can be used in Google to find many of the manuals. The MMC2107 PIT was derived from the 1998 MMC2001 "IT" Programmable Interval Timer. It didn't have this problem as it ran from a 32kHz crystal and didn't have a prescaler. The rest of the control register is identical though.
> I use (better our customers) the PIT for a long time on 5329 and I got no report about loss of counts.
Would you notice an error of 2 seconds per day? You might notice a 24% error, but that requires a huge prescaler, tiny modulus and a long delay between the ISR entry and the PIF clear. You need to be using a PIT and another timer, and expecting them to retain a fixed phase relationship to see this problem.
> I think we'd expect a FSL statement now 
Do you think they read this list?
I'm about to send note of this back through our distributor. I've already posted on CodeSorcery's Coldfire list.
I'm going to start referring to this peripheral as the "Bear PIT", taking the SECOND meaning in the following:
http://en.wikipedia.org/wiki/Bear_pit#Other_meanings
As far as I can tell,everyone who has read the PIT manual and then programmed this part has unwittingly toppled into the same two "Bear PITS", making the same two mistakes. Linux code, Freescale samples, "MrBean"'s code and mine (until I fixed it). For the last 10 years. In most cases this is relatively harmless. Who cares about periodic timer accuracy? Who cares if the first programmed time period is out by a factor of 1000? Some people might.
J2MEJediMaster wrote:
> You might also file a service request, calling out that the documentation needs enhancement/fixing.
I followed your advice, and after 3 weeks received the following:
I talked with the apps team and they told me that the redaction doesn’t seems to implies that writing the same value to the PRE bits doesn't reset the timer. Anyway they will review and make any necessary change if necessary. Thanks in advance for your feedback. Have a nice day.
Redaction? I can't see how a chapter which hasn't changed in over 10 years can be "redacted".
I was hoping for "it is misleading, we'll fix it". I'll keep waiting.
> I've done a fair share of embedded programming (8- and 16-bit), and nothing irks me
> more than struggling with a problem for days and then discovering that something about
> the documentation was the culprit.
And then I try to stop people making the same programming mistakes I've made. If I can't get the documentation changed at least Google can find this article. Try Googling "coldfire bear pit". I'm already getting this article at the top of the list and I haven't posted it yet .
