I am using s/w compare mode (MS=01, ELS=00) on a S08QD4. Clock source is FFL.
Constant value for TPMxCnV. No interupts enabled.
Code Warrior simulator shows that CHnF gets set when TPMxCNT = TPMxCnV as expected but cannot clear this flag immediately by reading TPMxCnSC and then writing zero to CHnF.
Is this a related problem?
Anyone got any suggestions?
Bill
Forget this, it works fine. I found the problem elsewhere in the application.
Bill
This is particularly relevant for the AC60 because, depending upon the configuration of CLKS and the selected mode, there could be a considerable time before registers TPMxCnVH:TPMxCnVL are updated. It is, therefore, important to ensure TPMxCnSC is not written during this time unless you want to cancel a previous write to the channel value registers.
As a result of these differences in the latching mechanism, you may have to initialise the timer registers in a different order than before to allow for this.
If the description of this functionallity was in the MC9S08JM60 manuals it would of save me a lot of time.
I am unable to see a way to solve this problem and make it portable across patforms. The only solution I can see is adding a fixed cycle delay, which is really bad coding.
Can someone offer a 'nice' way to do this?
//Start output event in 0x0100 counts, this could be called at ANYTIME, so it has to happen before TMPxCnSC.
TPM1C3V = TPM1CNT + 0x0100;
//Worlds worst fix; eat a few bus cycles, this must be greater than the slowest TMP tick rate (will change with bus frequency change and prescale change so I cannot see a way to make this code nice and portable across processors with different prescale rates and different bus rates as this code's speed will change with bus, and the TPM will change depending on its setings. Its also bad as it holds up the processor in interrupt eating up valuable processor cycles.
for(i = 0;i != 5; ++i);
//Set output on compare
//Enable interrupt
//Clear previously set interrupt flag
TPM1C3SC = 0b01011000;
This is ugly, surely I have missed an obvious way to make this work 'nicely'
Won't something like this work?:
char c;
c = TPM1CNTL;
while(c == TPM1CNTL){}
I guess it will work, but, if you have a very slow TPM rate and it ticks over straight after the update, you could end up waiting in interrupt an entire PCM tick eating up valuable processing power...
Maybe its just me, but, this update seems, well, dumb. Maybe I am still a little frustrated after spending a day working out this was the cause to all our problems after updating from AC16 to AC32.
Any other idea's? Is there some logic to why 'they' would do this? it just seems a step in the wrong direction...
Hello all,
The coherency mechanism for the V3 module differs whether the CLKSA:CLKSB bits within TPMxSC register are both zero, or not. When both bits are zero (the TPM clock is disabled) there will be immediate update of the TPMxCnV value, similar to the earlier TPM versions.
To avoid the more lengthy coherency mechanism, my suggestion is to alter TPMxSC so as to zero the bits, prior to writing a new value to TPMxCnV. Then restore TPMxSC to its previous value.
The suggestion in an earlier post, that any write to the TPMxSC register will reset the count value, I believe is incorrect.
Regards,
Mac
Thanks Bigmac, its always good to here from you.
Neither solution is ideal for our application as the TPM shares its resources with decoders and encoders and this output compare is forever setting up various short / long pulses both in and out of interrupt.
The RM suggest writing to TPMxCnSC prior to updating TPMxCnV, which is no good as if the tick is in the wrong spot, it will set the interrupt flag immediately after, or while the TPMxCnV is being updated, so its certainly a dangerous suggestion for some applications (like ours).
I am still completely baffled by Freescales reasoning behind this update. Oh well, time to move on...
-Denn
acno wrote:
HI,
The problem arise if I modify the status register (TPMxCnSC) after updating the channel value (TPMxCnV), in this case it seems that the new value is lost. If I touch the status register before updating the value, all is ok.