How to force PWM output

zorrotz · ‎05-07-2012

Hello,

I am using a TPM timer in edge-aligned PWM mode in MC9S08SH32.

During normal operation the channel value register sets the duty cycle of the PWM output signal, but on an external interrupt request I want to force the PWM output to 0. What is the best approach to do this?

Thanks in advance.

bigmac · ‎05-07-2012

Hello,

If you do not wish to truncate any pulse that may be currently active, simply zero the channel value register. Otherwise you can disable the channel by zeroing the TPM channel status and control register. But make sure you have already initialised the GPIO pin as output low.

Regards,

Mac

zorrotz · ‎05-08-2012

Hello,

I want to truncate the current pulse, but only the current pulse not the next pulses. So after forcing the GPIO the PWM should take the control of the GPIO.

I tried with this (note that TPM1SC is set to 0x08 to continue with next pulses), but it doesn't work because when the PWM is restarted the GPIO returns to the level indicated by the PWM.

        PTAD_PTAD0       = 0;
        PTADD_PTADD0 = 1;
       TPM1SC                = 0x00;

       asm (nop; nop; nop; nop; nop; nop; nop);
       TPM1SC                = 0x08;
       PTADD_PTADD0 = 0;

bigmac · ‎05-08-2012

Hello,

I suspect that you will need to control the point at which PWM output resumes. Within the external ISR code, in addition to disabling PWM operation, perhaps you could try setting operation to software output compare mode, with interrupt enabled. Then during the TPM channel ISR you would restore PWM operation. At this point, the output signal should already be low.

There would need to be sufficient time within the PWM period to complete the processing of both interrupts. This will dictate the upper limit for PWM frequency. The pulse truncation will be delayed by the external ISR latency (my guess is approximately 30 bus cycles best case).

If the asynchronous external interrupt event should occur when the output state is already low, the whole of the next output pulse would be suppressed.

If you need to avoid this, it is possible to determine whether the TPM count value exceeds a value slightly less than the channel value, and do nothing if so. But this extra code will further degrade the pulse truncation latency. You need to take into account the delay between the reading of the counter register and the enabling of the output compare interrupt, in relation to the negative edge of the output signal - this timing would need to be very closely controlled and would likely involve the use of assembly code for the ISR. Too early and there will be a short remnant pulse, and too late will suppress the next pulse

Regards,

Mac

.

zorrotz · ‎05-09-2012

Hello,

Thanks for the help.

The problem is that the ISR used to restore PWM operation can be delayed due to other ISRs (for example there are 2 PWMs working, serial communication, ....) and next PWM cycle could be lost.

The only solution I have found is to include this within the external ISR code:

     TPM1C0SC = 0x1C;
     TPM1C0V = TPM1CNT + 11;
     TPM1C0SC = 0x3C;

Setting channel in output compare mode enables to load immediately in the channel value register a value slightly greater than the TPM counter, and then restore PWM mode.

But this approach includes a delay between external interrupt and GPIO change.

Regards,

zorrotz

bigmac · ‎05-09-2012

Hello Zorrotz,

I might have thought that the latency prior to the execution of the interrupt pin ISR would be equally problematic, as the restoral of PWM operation. I have no idea of your PWM frequency, duty cycle range, bus frequency, and what sort of delays you can tolerate. However, I can see some problems with your current approach. I assume that your interrupt event is asynchronous relative to the PWM waveform.

After you alter the TPM1C0V setting to an indeterminate value, you do not restore the previous value prior to the next PWM cycle. Without restoral, the following PWM duty will be unknown.
I would have expected that you would wait, within the ISR, until the compare event had occurred, and only then would have restored PWM operation.
It is potentially possible for the compare value in TPM1C0V to exceed the value in TPM1MOD register, with the result that the compare event will never occur. It is also evident that, if the delayed TPM1CNT value should exceed the PWM duty value within TPM1C0V, the PWM output will already become inactive, and no compare event would be necessary. This test would also help alleviate the other problem, provided the PWM duty does not exceed a maximum limit somewhat less than 100 percent.

Within the ISR, the following code may overcome these issues. However, the DELAY period may need to be substantially increased from a value of 11. You will need to determine the number of bus cycles between markers (1) and (2). Then divide by the TPM1 prescale setting.

word duty, count;

duty = TPM1COV;            // Current PWM duty
// (1)
count = TPM1CNT + DELAY;
if (count < duty) {
   TPM1C0SC = 0x1C;        // Set output on compare
   TPM1C0V = count;
   TPM1CSC_CH0F = 0;       // Clear flag
// (2)
   while (!TPM1C0SC_CH0F); // Wait for compare event
   TPM1C0V = duty;         // Restore previous value
   TPM1C0SC = 0x3C;        // Low true PWM mode
// (3)
}

To determine the maximum allowable duty value within TPM1C0V, use the number of bus cycles between markers (1) and (3), again divide by the TPM1 prescale value, and subtract this amount from TPM1MOD.

On a completely different tack, if the uncertain interrupt latency due to the occurrence of other interrupts is too much for your application, you might also consider the use of additional hardware to gate the PWM output, with sub-microsecond latency. For each PWM channel, the additional hardware would consist of a D flip-flop stage (say 'HC74), and a single 2-input NAND gate, i.e. the addition of two packages to cater for both PWM outputs.

Regards,

Mac

zorrotz · ‎05-10-2012

Hello Mac,

Thank you very much for your reply.

I had have into consideration the problems you see and all the code within the ISR is (note that there was an error in my previous replies and I wrote the code for set output on compare instead of clear output on compare):

if ((1 == PTAD_PTAD0) && (TPM1CNT > 246))
{
TPM1C0SC = 0x18;
TPM1C0V = TPM1CNT + 11;
TPM1C0SC = 0x38;

TPM1C0V = 340;

}

- With this condition the ISR can only clear the output if TPM1CNT is > 246 and < 340, so problem 3 is fixed.

- TPM1C0SC = 0x18 is done before TPM1C0V = TPM1CNT + 11 just to write in TPM1C0V register as soon as posible

(because of the latching mechanism of TPM1C0V)

- TPM1C0V = 340 is done after restoring PWM operation, so due to the latching mechanism 340 is copied to TPM1C0V

when current PWM cycle ends.

I am running this code and it works, but I can't solve the delay problem (delay due to the if condition and the way to force the change of the GPIO).

I have to do more tests and see if this delay doen't damage the IGBT controlled with the PWM.

Regards,

Zorrotz

bigmac · ‎05-10-2012

Hello Zorrotz,

zorrotz wrote:
I had have into consideration the problems you see and all the code within the ISR is (note that there was an error in my previous replies and I wrote the code for set output on compare instead of clear output on compare):

Setting the output on compare seems totally consistent with lthe use of "low true" PWM mode. The output pulse is considered to be active low for TPM1CNT values from 0 to TPM1C0V, and then inactive high up to TPM1MOD. I am not sure whether there is some confusion about this point.

If this is a protective mechanism, and the maximum latency is critical, my personal view would tend towards the hardware gating proposal as the more reliable solution. If the execution duration of another unrelated ISR were to increase, due to future code modification, this could potentially cause an unexpected, and difficult to diagnose, system failure.

Regards,

Mac

How to force PWM output

How to force PWM output

General