Changing PWM Frequency with ST72264

[torrey]

Posted on February 24, 2005 at 11:22

Changing PWM Frequency with ST72264

[torrey]

Posted on February 23, 2005 at 14:10

I am trying to work with the timer-based PWM on the ST72264 and have been having some problems. I think I may have figured out a solution (thanks to reading the messages on this forum), but I would like to see if my logic makes sense.

First of all, my project involves reading values from two different channels on the ADC, then converting them to two different PWM frequency values (one for each timer). The fCPU is 8MHz, the PWM frequency is 1MHz, and the PWM output starts with a constant 2us (2 count) high with the remainder of the period being low. On my first shot with this software, I tried to change the OC2R register in the main part of the code. This means the change could occur at an arbitrary point in the timer count. From what I read here, if the OC2R loading occurs too close to the end of the PWM cycle, then it will prevent the compare from being carried out, which corrupts the PWM cycle. I thought I fixed this problem by buffering the OC2R value, then only loading it on a ICF1 interrupt event. This greatly improved the consistency of the PWM, but not entirely (the cycles drift with respect to one another, even if they are theoretically on the same period). Then I noticed that the time profile of the ISR routine is very close to the initial pulse width of 2us. This means that the OC2R value update could be occurring close to the first compare of the PWM. Inserting a 2us+ delay at the beginning of the ISR seems to resolve the issue entirely. To make a long story short, my theory is that any alteration of OC2R will prevent a compare from taking place for either OC2R OR OC1R. My best solution is to try to only change the OC2R when ''far'' from any compares. Is this theory correct or is there another explanation/solution that I haven't thought of? Any thoughts would be much apprecated. Thanks.

[wolfgang2399]

Posted on February 24, 2005 at 05:08

Hi Torrey,

perhaps it helps you paying attention to the order of writing OCxHR and OCxLR. Have a look therefore at the notes on page 62 of the datasheet: 1. After a processor write cycle to the OCiHR register, the output compare function is inhibited until the OCiLR register is also written.If you are using the COSMIC C-Compiler there will be no problem using the comand OCxR = short_word ;. But using assembler or the HiWare-Compiler you have to force your program to writing the MSByte first. There may also occur a problem in reading the ICxR. Please pay also attention to the notes on page 59 thereupon. Hope it helps WoRo

[torrey]

Posted on February 24, 2005 at 11:22

Thanks for the suggestions. I did make sure to write OCiHR first, followed by OCiLR (based on Note 1, page 66). Since I'm using interrupts, I also made sure to clear the interrupt based on ICF1 (Note 3, page 66) by reading the CSR follower by IC1LR.

However, I did find something on page 59 that may have solved my problem. Note 5 indicates that ICAP1 and ICAP2 are always connected to the timer (and I am using these pins as general I/O). I assumed that PWM mode would prevent these from triggering ICFi the interrupt (which is the same as is triggered by the PWM). It seems that this may not be the case. By reading both ICiHR registers, I inhibited the input capture functions (Note 1, page 59). This seems to avoid any unexpected interrupt triggers and stabilize the PWM. I'm not sure if it is necessary for both ICAP1 and ICAP2, but I need to try it. It should definitely be necessary for ICAP2 since it is possible to use this function in PWM mode. I never thought that using the PWM would end up this complicated. Hopefully ST will add some additional notes on this function in the future. PS: I am using SofTec's STVD7 for inDart and writing in asm.