THE 9S08 TIMER - HOWTO'S

[BooleanBob]

Hello friends !

There are some cases in which using the timer gets hard for me. I've been using timers since the 68HC11 times but sometimes trying to make it work in simple tasks, combining two or three interrupts ( Input Capture, PWM Output Compare and Overflow ) all combined, things don't go right and the results are weird.

Please correct me if I'm wrong, but for me the center issue is the way the timer is designed and know the working rules exactly. Generally the problem comes when trying to set an Output Compare value that is different from the previous used value, to generate an interrupt and also to abtain an output signal from the associated timer pin.  I would like to know  the rules. When can I program a new valid value related to the timer TCNT overflow without missing cycles  ? I have read many documents and application notes, including the datasheet for the M9S08QG8 ( in my last application ) and it say little about the timer rules. In older chip manuals such as the MC68HC908 line , there was advice about missing complete ( one or even two full timer cycles ) whenever the value of the output compare was changed before the main counter reached its  overflow ( FFFF -> 0000 ).

Some questions here to be more precise in my questions:

1. is it correct ( and "neat" ) to stop and completely reset the timer to ensure a clean, new Output Compare cycle ?
2. can the next Output Compare value be programmed and be effectively valid even if there was no Overflow between these changes ?
3. is it mandatory to center all the operation in the Overflow event to get precise Output Compares without losing cycles or having erratic behaviour ?
4. is there some complete literature about these timer issues that I could read ?

Thank you in advance

Roberto

[BooleanBob]

Hello Mac:

Thank you for your kind reply. Maybe my last posting has been written confusingly, and I have badly expressed what the goal is in my application. I suggest to take a look at my attached code and the Freescale's manual paragraph, which is the simplest working example of what my application exactly needs and cannot ( at this time ) be generated by simply reprogramming the Output Compare register without stopping the timer and without using the Overflow event as a reference. You can see the results using two channels of an osciloscope.

1. The Output Compare ( not the Input Capture ) subsystem is totally dependent of the Overflow event, as is explained  in the paragraph taken from the older AP64 manual, and in your own words. I have noticed that the overflow event  is in charge of reloading the Output Compare internal register ( not the one you write the value in ), and its contents is transferred on main counter overflow. This is the reason why the Output Compare event can be missed depending on the moment and absolute value loaded in the Output Compare register, in relation to the overflow event. If you keep this value constant, you will never miss a Compare. If the new resultant reload value falls before or after the overflow event, you will have to make calculations because the overflow will reload the next value for the next compare. In resume, you can't use this timer just as a one shot retriggereable monostable Flip Flop to produce output pulses. You can do it but you need to calculate your position every time, and that means extra software and the use of the overflow interrupt. Now that I know this, I will try to find the way to make it work.

2. Generating PWM is an easy task in which you don't need to stop the timer, because usually you don't need to synchronize the PWM signal to any external event, which is not my application's case. PWM generation is simple because the Output Compare value is always loaded in a moment in which the Overflow event has recently occured, so you cannot have conflicts. In my application, an external signal ( mains zero crossing ) is the master event and all the rest comes after this. For my application to work properly, I would need to synchronize the TPMCNT counter Overflow event with the zero crossing event, which is impossible unless you stop the timer and reset the counter on the Input Capture event that I use for the external signal.

3. YES you can use ANY interrupt to simulate the power line zero crossing, if you don't need to fire a real TRIAC by phase shift and you only want to see the complete scene on an osciloscope. This won't work in real life because, as I said before, you need to sync the power line to the timer, but is enough to see how the timer system responds to Output Compare in relation with the Overflow event.

4. The input Capture is very handy to take an instant picture of your counter by hardware to catch the moment in which some event happened in the outside world. Many applications are sensitive to software and interrupt(s) latency time, but it is not normally the case in a power line application, in which you have 10 ms events and you are using 478 uS timer tics. So The input Capture interrupt is being used just because of the double edge hardware detection capability and not because of the latching action of the register. Even if you get the value "by hand", it will also work fine in this case.

Resuming: it would be nice to leave the timer running free and obtain the result of the attached example without using extra software and Overflow events.

Again, thank you for your help.

Roberto Berner

[JimDon]

Bob,

First, could you clarify which chip you are using?
Are you using HCS08, or HC908 family?

You can not mix the two. All I say refers to the HCS08 family, S08TPMV3,

What you are saying about the output compare registers is generally not true, and would make the feature pretty useless. In OC mode, the data is transfered:

If (CLKSB:CLKSA not = 0:0 and in output compare mode) then the registers are updated after the
second byte is written and on the next change of the TPM counter (end of the prescaler counting).
In other words, in OC mode the overflow has nothing to do with the transfer of the register data.

This means that the next time the counter counts, it gets loaded.

How ever if you have the PWM enabled then:
If (CLKSB:CLKSA not = 0:0 and in EPWM or CPWM modes), then the registers are updated after
the both bytes were written, and the TPM counter changes from (TPMxMODH:TPMxMODL - 1)
to (TPMxMODH:TPMxMODL). If the TPM counter is a free-running counter then the update is
made when the TPM counter changes from 0xFFFE to 0xFFFF.

As for using say the KBI interrupt, there is no reason why this will not work, as the purpose is to sync the one shot to the line frequency.

[BooleanBob]

Dear forum friends:

Thank you very much for your posting and for the different examples, explanations and code ( Mac ) about the timer howto`s. Of course this information opens my mind and makes me think in many ways to use the timer. I would like to point you out that my initial goal ( and probably still is ) to make the timer work with the less amount of software involved by using the automatic pin driving functions offered. YES I could make this work many times by operating the pin manually but it is just that I wanted to climb one more step. Any way, I can live with the manual option too. I believe that preserving the modulo and not stopping the counter is always the best option, because the free running timer could be needed for something else.

I will read your code Mac ... it sound very interesting no matter the TRIAC issue. I will be back to you guys with some experiments done based upon all these kind contributions.

Thank you again
Roberto

[BooleanBob]

Dear friends, it´s me again. Well ... I have made some research on this and this is my first attempt. I works fine but unfortunately I yet couldn´t find the way to leave the main timer running al the time.

Here is the code ... it is just an osciloscope test. I used the MTIM to simulate the 50 Hz mains zero crossing input. This interrupt should be changed to be Input Capture on channel 0 in real life, signal that is taken from the zero crossing detector. Somebody may find the "timer.h" module useful. This is my two pennies. My test runs in a DEMO9S08QG8 board. PTB6 outputs a "line sync" signal and PTB7 is output for the TRIAC.

I will keep on reading and researching, but here is my comment at this point. With all my respect, my conclusion is that this timer has a very important functional consideration regarding the main counter overflow synchronism dependency. There is an extremely important paragraph taken from the MC68HC908AP64 Rev. 3 8/2005 manual @ page 138 9.4.3.1 " Unbuffered Output Compare" , that is also repeated in many other manuals. It was obviously removed from the new chip versions. The text is confusing, but one can understand what it means using a bit of imagination and navigating among the poor, not revised semantics. This explains why this timer - in the way it has been designed - cannot take full advantage of a wide range of applications and other many possibilities. It has been thought just for PWM use. IMHO I would have added a couple of bits in some register to allow some "extras" to sometimes disengage the logic from the overflow event at the moment of  reloading the new compare value. Allow me to copy (literally) this small paragraph here, that can be perfectly applied to the QG8 with some imagination and can help somebody else:

"Any output compare channel can generate unbuffered output compare pulses as described in 9.4.3 Output Compare. The pulses are unbuffered because changing the output compare value requires writting the new value over the old value currently in the TIM channel registers. An unsichronized write to the TIM channel registers to change an output compare value could cause incorrect operation of up to two counter overflow periods. For example, writing a new value before the counter reaches the old value but after the counter reaches the new value prevents any compare during that counter overflow period. Also, using a TIM overflow interrupt routine to write a new, smaller output compare value may cause the compare to be missed. The TIM may pass the new value before it is written.

Use the following methods to synchronize unbuffered changes in the output compare value on channel x:

* When changing to a smaller value, enable channel x output compare interrupts and write the new value in the output compare interrupt routine. The output compare occurs at the end of the current output compare pulse. The interrupt routine has until the end of the counter overflow period to write the new value.

* When changing to a larger output compare value, enable TIM overflow interrupts and write the new value in the TIM overflow interrupt routine. The TIM overflow interrupt occurs at the end of the current overflow period. Writing a larger value in an output compare interrupt routine ( at the end of the current pulse ) could cause two output compares to occur in the same counter overflow period."

I don´t mean that correct behaviour cannot be achieved, it is just that it takes a certain amount software overload to analize these exceptions. Some of my questions here are:

1. considering this explanation, what means unsynchronized ? ( I think it is related to the overflow event )
2. what is smaller value /larger value , are these absolute values or they consider the overflow modulo ?

My next step is using the overflow interrupt ( absent in my code example ) to monitor these exceptions and splitting the desired results scenario in 3 phases that must be considered to reload the compare register and avoid stopping the timer.

I apologize for having used so much space and time, and please correct me if I am wrong in any of my thoughts.

Kind regards
Roberto Berner

Triac_test1.zip

Message Edited by t.dowe on 2009-10-27 12:17 PM

[bigmac]

Hello Roberto,

I think I should make a few comments about input capture and output compare operation of the TPM module, where there might possibly be be some confusion.

1. The IC and OC operates quite independently of overflow, and its associated interrupt, provided the period between capture events, and between compare events is always less than the overflow period.  For intermediate periods, up to 10 ms in your case, this can be achieved with suitable setting of the TPM prescaler.  The timer overflow interrupt could be disabled or enabled, depending on other requirements of the project.
2. You cannot exactly simulate input capture operation using the MTIM since the two modules use different counters (so are asynchronous).  Input capture mode provides the counter value when the capture event actually occured (a hardware event, and different from the case where the current counter value is read from within the ISR).  Using the input capture value will avoid the effects of any (potentially variable) latency in the handling of the interrupt after each event has occurred.  Directly reading the current counter value is likely to result in inaccuracy and jitter of the intended firing angle for the triac.
3. This stability of the trigger waveform is the primary advantage of using input capture over other triggering methods.  The only drawback that needs to be considered is that there will be a minimum allowable delay from the zero crossing until the start of the trigger waveform.  But this should not be too onorous for your application, when using a relatively fast bus frequency.
4. If you wish to "simulate" operation without using a zero crossing detector, you will need to alter the input capture channel to operate in output compare mode, using 10 or 8 ms between compare events.  You would need to use the current channel reading, as the equivalent of the input capture reading, prior to updating the channel for the next compare event.

The attached project is intended to demonstrate the the input capture/output compare approach.  The code is untested, but might represent a starting point for experiment.  The project will accommodate variation of mains frequency (the half-period is measured), and allows to stipulate the required conduction angle for the triac.

Regards,

Mac

phase_ctrl6.zip

Message Edited by t.dowe on 2009-10-27 12:16 PM

[BooleanBob]

Dear JIm:

1. In my previous posts and in my software attachment it is clear that I am using the 9S08QG8.

2. The timer functionality REFERRED TO OVERFLOW AND LOADING is the same on both families, even in the HC11, where all this started.

3. You are talking about the way you write a value to a register. YES is true that that in the 9S08 famiIy you can now write the register in any order to optimize for eg: C languaje code. I am talking about the way the values once stored in their registers, take effect. It is not true that the value takes effect that simple and works right away, as I exposed before.

4. I don't understand what you mean with the keyboard interrupt. In my case and as I explained before, this is inmaterial because any source of interrupt will do for me. Please understand that just in case somebody could be interested in this case and would like to exercise the problem, it is better to simulate the scene with any interrupt to watch the process in a single osciloscope and using a demo board. I don't pretend that you are going to set up a TRIAC :smileyhappy: If it works this way, then you can switch to the interrupt you like better to sync to the power line.

What I am trying to solve here is quite a lot more deep and precise, not just a matter of how to write in a register. If what you say is true, then please be so kind to upload a working piece of code to demonstrate that my point is wrong, trying to read the previous material that includes the details that you are asking for in your post.  To be precise: do you know how to achieve this ( all what I have been exposing ) without stopping the timer ? Please teach me how to do it or tell me where is may reasoning flaw. I am willing to learn , based upon facts.

Believe me that the timer - sometimes - is not as easy as it should ...

Kind regards

Roberto Berner

[JimDon]

No, I am not talking about the way you write a value.
This quote from the spec sheet makes it quite clear that the compare register is loaded from the buffer register on the next clock to the counter, not the overflow of the counter (in OC mode):

"If (CLKSB:CLKSA not = 0:0 and in output compare mode) then the registers are updated after the
second byte is written and on the next change of the TPM counter (end of the prescaler counting)."

Of course writing to the registers is a pre-condition for the value to be transfered to the compare register, but that is not the point I am making.

There is no need to stop the timer.

TPM1C0V  =    TPM1CNT + MY_DELAY;

On the next clock to the counter, the new delay value will be loaded to the compare register, and the OC will happen when the value in the compare register is equal to the value in the counter. If MY_DELAY happend to be very small, I suppose it could be that the count you set would be missed, but I don't think that is the case here.

I can assure you that this works, and you need to make sure that your code is setting the OC mode correctly and loading values as expected

[BooleanBob]

No offense Jim, please don´t take it bad. I already tested your point of view during last weekend. I can upload the bad code and this is why I am taking the forum´s valuable time.

It does not work. For sure I am doing something wrong but I am used to have it beautiful in the manual and there is always the other side of the coin.

Please write a piece of working code for me to test it. I was also sure that it had to work fine when I first RTFM. To my knowledege, it is the same old story from the HC11 up to our days.

Best regards
Roberto

[kef]

Don't talk about HC11 bad :smileyhappy:. Perfect timer, which never had problems you are talking about. Did you read HC11 pink book? Here it is, with great examples how to generate pulses, how to measure time periods longer than 2^16 timer ticks etc ect http://www.freescale.com/files/microcontrollers/doc/ref_manual/M68HC11RM.pdf

Take advantage of free running counter. HC11/12 had/have single counter and 8 channels. That's equivalent to 8 independent timers. Long (>2^16 ticks) pulses/periods generation has nothing to do with overflow flag, and Mac has showed how to use that in S08. Measurement of long (>2^16 ticks) pulses/periods requires having shared overflows counter. This is what for overflow interrupt may be required..

You also don't take it bad, but are you reading what others say? Mac and Jim are right and you are looping at something obvious. Didn't Jim said that you should set TPMCH relative to TPMCNT? Why then in your macros-obfuscated code, in MTIM overflow handler, you are writing absolute value to TPMCH and  not TPMCNT relative value?:

 m_QG8_set_TPMCH1_value(angle);

Where's  +TPMCNT? It should be simple. Counter is free running. So you should synchronize to it adding current counter value to your angle.

Please stop telling horror stories about TPM and HC11. That's simply not true.

Regards

Message Edited by kef on 2008-06-20 10:30 PM

Message Edited by kef on 2008-06-20 10:32 PM

[BooleanBob]

Ok friends, I see that I have been wrong for a lifetime. I am 53 and I started 6800 at 19. I agree that he timers since HC11 are very good. I have meade a living out of HC11. Respectfully , I still feel that you really are not paying attention at the problem here. I don´t know why, but you are insisting in a mode that works for PWM but you are probably not understanding what I am talking about. I´ll try to gather some more information.

Do you really think I cannot tell the difference between the absolute value or the value related to the module ? Do you think that this timer really works as you are saying ? Again: please probe it. Write a simple program and show your point.

I don´t want to bother with my questions here, so I will try to consult somewhere else. I am sorry if I had upset you and your friends, but my style is cooperation and facts, which I don´t feel is yours.

Take care !

Roberto

[kef]

Roberto,

I don't understand what problems you are talking about. There were some nuisances in old HC08 regarding buffered/ not buffered PWM. Are you talking about that? But for you triac and firing edge you don't need PWM. Do you insist on using PWM for triac?

Yes it looks like someone (maybe I) doesn't see something obvious.

Here's my code. It's for QE, I don't have QG. I'm triggering TPM1CH0 imput capture (your zero-crossing signal) pulsing output pin tied to IC pin. Output compare pulse is generated on TPM1CH1. It's all is pretty the same like on HC11. Please see attached code and oscilogram.

Regards

[BooleanBob]

Dear friends kef and all...

Definitely: I REFUSE TO USE PWM and I REFUSE TO STOP THE TIMER.
Thank you so much for the pictures and code. Believe me that you are not wasting your time, and I appreciate your politness, it is my fault to be sensitive to the form the things are said.

YES I know some about the timer problems and its use because I have been designing electronic ignitions for  automotive terminals providers for the last 10 years. My first experience was with the HC11 ( attached picture of one of my old HC11 boards ). Then the HC908 followed and YES it has problems with the buffered/unbuffered issue. As you all know this was a workarround for the problem I am trying to solve with 9S08 but the problem with the timer is still there.

I think that your code ( I´ve just received the file and I couldn´t open it yes ) includes what I was talking about using the Overflow Interrupt ... I don´t know but I promise to take a look at it. Let me remind you guys that my goal is to fire the triac with phase angle without stopping the timer and to keep the gate signal all the time until a little before zero crossing. So the Output Compare has up to 3 jobs during the mains semicycle. I couldn´t make it work without forcing the sync by stopping the timer, and never reloading the Output Compare 3 times during the same semicycle ... I believe the Overflow interrupt is needed if variable angle is used.

Let me take a loo at the code and be back yo you.

Greetings

Roberto

HC11PRO_web.jpg

Message Edited by t.dowe on 2009-10-27 12:15 PM

[peg]

Hi Roberto,

I have made very extensive use of simultaneous IC, OC and OFLOW interrupts on one timer at frequencies in the range of 1 to 18kHz. I have done this on HC05, HC08 and S08 without any problems and without ever resetting the timer. It is unclear to me EXACTLY what your problem is here.

A point that seems to be missed here (and correct me if I am wrong) is that you are burst firing the triac and that the burst is being generated directly by the MPU rather than simply gating another source.

This means that at the desired phase angle after zero-cross you start pulsing the triacs gate at a few kHz or something and continue to do so right up until the next zero-cross. This is done to prevent the triac dropping out early on strange loads.

This of course makes it more complicated than some have indicated but still well within the capabilities of the TPM. None of the delays should be anything like the overflow period and as such the fact that the timer overflows and wraps around can be completely ignored.

Can we go back closer to the beginning (prior to the slanging matches and CV's) and state more precisely where you believe the problem is without vague reference to old mostly forgotten issues with previous devices.

[peg]

Or perhaps the OP is just talking about leaving the gate "on" from the trigger point until the next zero cross?

[allawtterb]

---

peg wrote:
Or perhaps the OP is just talking about leaving the gate "on" from the trigger point until the next zero cross?

---

He did say turning it off right before the next zero crossing starts, of course if he tries to cut it too close there will be problems and the triac will be on for the next half cycle as well.  I don't think he wants to pulse it several times during a half cycle.

[peg]

Hi,

Yes quite possibly just on rather than pulsed.
Most of my experience with these things is in the 1000's of amps range, big hockey puck inverse parallel SCR's, water cooled and most relevant here - pulse transformers.
I guess with smaller more modern sensitive gate, lower hold-in current devices you have to be careful about going just past the zero cross, you might get a full cycle for the next half cycle.

[BooleanBob]

Thank you JImDon, kef,Peg , allwtterb, Bigmac, Ake ...

I was wrong to consider this timer the same as the HC08. Thank you for the contributions and valuable advice. Kef I followed your code "main2.c". I could make it work. No timer stopping , no Overflow event interrupt. Peg and JimDon you are right. When firing SCRs and TRIACs with heavy loads ( high power brush motors and soldering machines ) you need to burst the gate as you know that the load is almost a short circuit full of sparks and the device disconnects repeatedly from the load ( ~2000 to 5000 Amps ). An external oscillator is used to drive the gate circuit @ 20 to 50 KHz. In some applications you can hold the gate until the semicycle dies and the TRIAC stops conducting because it doesn´t have enough sustaining voltage. I like to stop the gating before this. For this reason, as you all know there is a dead firing zone of about 6 degrees after and before zero crossings.

Working code and oscillogram uploaded.

Thank you again friends and kind regards

Roberto

triac_071.zip

working1.jpg

Message Edited by t.dowe on 2009-09-22 11:45 AM

[JimDon]

---

peg wrote:
Or perhaps the OP is just talking about leaving the gate "on" from the trigger point until the next zero cross?

---

That was his orginal plan. I see a problem with that, as it could cause the traic to trigger at tha start of the next half cycle.

[allawtterb]

Jim, kef and bigmac are all correct.  There should be no reason to reset the counter.  On input capture add it to the time you want to wait until the turning on of the triac and set the output compare to this value.  I don't see any reason to not have the output compare to set the pin automatically, setting it manually just adds an extra delay.  The method described by bigmac is the exact method I use to dim lights on my high voltage dimmer boards(I work for a company that makes lighting controls).  I can post an example of the code that I use but it is exactly as bigmac has described.

[JimDon]

I certainly said quite the oppsite. You DO NOT want to use PWM mode. You DO want to use OC mode.

Nothing I have said  applies to PWM mode. Do not use PWM mode.

CPWMS should be 0 and MSnA should be 01.

If you were setting anything other than this, it will not work as I have said.