HCS12 - Strange PWM Issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

HCS12 - Strange PWM Issue

645 Views
andrearicco
Contributor I

I'm working on an old project based on HCS12 for a temperature PID control where PWM5 is used to drive an SSR. Following the init of PWM unit:

 

output( PWMCTL, input( PWMCTL ) & ~12 ); // PWM reset wait e freeze bit
output( PWMSDN, 0 ); // PWM shutdown register (disabled)

 

   /* channels 6,7,3,2 takes source from (S)B clock: HI FREQ PWM */

  /* channels 4,5,1,0 takes source from (S)A clock LOW FRAQ PWM */

PWMCLK   = 0xFF;    // all sources from scaled clocks

PWMPRCLK = 0x07;    // Prescaler select A/128 B/1

PWMSCLA  = 0x00;    // scale value clock SA (0 == 256)

PWMSCLB  = 0x00;    // scale value clock SB (0 == 256)

PWMCAE   = 0x00;    // all left aligned signals

PWMPOL   = 0x00;    // normal polarity (1-0)

 

PWM5 is used with 8 bit, it is enabled at the beginning and never stopped, PWMPER5 is at default reset value 0xFF and never changed so the period is about 2090 ms. More or less every 1200 ms PID algorithm set a new duty value writing PWMDTY5 asynchronous with respect to PWM unit so the last value written before period ends shall be the new value for the duty.

Usually all it works fine, but sometimes (once in 3-4 hours) starting from a steady temperature we have notice that PWM has a strange behavior like PWMDTY5 was loaded with 0xFF even if monitoring pid output this value is not written in the register, infact once the temperature is stable duty value from PID are about few units.

What we have noticed is that this always happens if duty value is written immediately after period end, when PWMCNT5 should be 0 if i'm right since conter is increased every 8 ms. I've attached an image with yellow trace for the PWM (it is negated by hardware port) and green trace for debug pin befor (high) and after (low) PWMDTY5 writing.

I was wondering if some have you have ever seen phenomena like this or have something to suggest to me like workaround.

Thanks

20638_20638.bmpscope_15.bmp

 

20648_20648.bmpscope_16.bmp

Labels (1)
Tags (3)
0 Kudos
3 Replies

391 Views
iggi
NXP Employee
NXP Employee

Hi,

i've been reading this several times to understand the issue you are having. Well i did, but still don't have exact clue about the cause.

What exact HHCS12 device you use? We can check possible errata (based on the maskset number).

The S12DP512 datasheets provide the following statement for the PWM Period and Duty:

"Dedicated period and duty registers exist for each channel and are double buffered so that if they change

while the channel is enabled, the change will NOT take effect until one of the following occurs:

• The effective period ends

• The counter is written (counter resets to $00)

• The channel is disabled

In this way, the output of the PWM will always be either the old waveform or the new waveform, not some

variation in between."

Regards,

iggi

0 Kudos

391 Views
andrearicco
Contributor I

Hi,

sorry but the problem wasn't easy to describe, anyway I try to summarize it: if you write PWMDTY in a specific moment it's like you wrote 255 whatever was the desired value. I'm sure we are not writing 255 since PID algorithm limit it to 244 and moreover we have logged that variable and we didn't find 255 as we expected.

Looking at the osc. traces our feeling was that the issue happened if we wrote PWMDTY when PWMCNT changed from 255 to 0, then we modify the FW adding a test on PWMCNT (PWMCNT > 3 && PWMCNT < 252) to allow PWMDTY writing. With this modification we didn't watch the phenomenon anymore, but we haven't understood which is the real cause .

By the way we are using M9S12DG256CPVE 0L01Y

Thanks and regard

0 Kudos

391 Views
iggi
NXP Employee
NXP Employee

Hi,

i've checked the errata sheet for this maskset and there are some PWM errate, but any related to this case.

MSE9S12DT256_0L01Y Mask Set Errata

I really don't have exact explanation for this strange issue. Maybe you just discover a new errata.

Anyway, it is good you havefound a workaround, so it doesn't happen anymore.

Regards,

iggi

0 Kudos