Page 1 of 1

Slew rate difference between PWM A0 and PWM B0

Posted: Tue Jun 11, 2013 7:24 am
by fd9750
Hi,

This is a bit of an odd one. I am using various PWM outputs, Among them PWM A0 and B0.
I have set the slew rate control registers to maximum slew rate by setting SRE_SDHC in register SRCR_SDHC to 3.
This should affect the slew rate of both PWM A0 and B0.
It does work well for PWM A0, the rise and fall times are only a few nanoseconds.
The same applies to all of the other 5 PWM signals I am using.

PWM B0 though does not perform as well, there the rise time is +/- 20 nanoseconds while the fall time is +/- 15 nanoseconds.

Initially I thought it was due to what it was connected to so I disconnected it completely but it stays the same.

Does anyone have an idea or suggestion that can explain it?

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Tue Jun 11, 2013 8:44 am
by Ridgeglider
Maybe its due to different pullups or connections that are on the various PWM lines on the demo board?

47K pullups are on the on the SPI/Sdcard lines (SPICS1,2, SPI_DOUT, SPIDIN, SPI_CLK).

On the Nano, P3:13 is also used for U2RX and maybe driven as an input unless the demo board jumper JP7 is removed. The PWM_B3 output is also used for U2 RS485 Tx and so it also drives a serial buffer.

On the Nano, the P3:15, SPI_CS0,PWM_A1 is the only line w/o addl connections.

Are you on the Nano or Mod?

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Tue Jun 11, 2013 2:46 pm
by Ridgeglider
I got curious about the Nano PWM code and tried the Rel2.6.2 example which as I understand it is supposed to produce either a 8.3mSec period (Center Aligned) or a 4.16 mSec period (Edge Aligned) PWM signal at ~6% duty cycle on Nano Pin 35= P1:35 = P3:20. When I didn't produced the expected output I added a routine tha twaits for a CR and toggles Pins[35] manually hi/lo using OSTimeDly(1) for 50 msec at each level to be sure I was on the correct pin (P3:20).

Code: Select all

    int i = 1;
    while(!charavail()   ){
		#ifdef NANO54415
			Pins[pin]=1;
			putleds(i++);
		#elif defined MOD5441X
			//MOD54415
			WriteLeds(i++);
			J2[pin]=1;
		#endif
		OSTimeDly(1);

		#ifdef NANO54415
			Pins[pin]=0;
		#elif defined MOD5441X
			//MOD54415
			J2[pin]=0;
		#endif
		OSTimeDly(1);
    }
I seem to be on the right pin. Have tried another PWM pin, P1:16 = P2:15 = PWM_B3 with no luck either. What am I missing?

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Tue Jun 11, 2013 7:10 pm
by mbrown
Hm, I seem to remember running into a problem like this writing the example, and I could have sworn it was all worked out but I can't tell you off the top of my head how to fix it. I've retested the example for all the PWM pins on the Nano module and it looks like you should have no trouble getting it working with pins 13, 15, 31, and 37. Just redefine pin at the top. Looking at the list, it looks like only the A lines are working. Let me look at the code again and see if there's something wrong with the way the B lines are initiated.

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Tue Jun 11, 2013 8:58 pm
by Ridgeglider
The PWM_A2 pin P3:22 works...! will check A vs B more tomorrow.

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Wed Jun 12, 2013 7:44 am
by Ridgeglider
mbrown: you are correct. Thankyou. Using the 2.6.2 PWM example for the Nanao, all four A channels work. None of the B channels work.

Here's another question related to the example PWM code: It includes functions to init a PWM wave form, and I can call it multiple times with different duty cycle values to modify the duty cycle. However, there must be a quicker way to simply update DC other than restarting the entire wave form. I tried calling CheckLoadOKClear() before (and after) loading the appropriate "pwmoff" value registers, eg: sim1.mcpwm.sm[3].val[3] for PWM_A1 (connected to pin P2:16). Alas, no luck... Ideas?

Finally, sorry to fd9750 for hijacking this topic from the original PWM question to ones about the PWM example. Fine with me to move my questions to a new topic if anyone wants to.

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Wed Jun 12, 2013 3:04 pm
by mbrown
Okay,

I think I have an answer now and probably have a few notes to add to the example in the future. The B pins do work, but I can only seem to get them to come on if you also have the corresponding A channel pin also on. I haven't been able to confirm this with Freescale yet, but my suspicion was that since this was designed as a motor control module, it assumed if you were only going to use one channel, you'd use A, and B couldn't be active unless you were using both PWM pins.

As for changing the pwm after initialized, you simply need to update the values to whatever you want then call InitializeModule();

If you want to use the pin, pwmOn, and pwmOff variables, the following function should do it

void UpdatePWM(int pin, int StartCnt, int reset, int pwmOn, int pwmOff)
{
int submod;
bool AnotB;

#ifdef MOD5441X
switch(pin){
case 19 : submod = 3; AnotB = 0; break;
case 25 : submod = 0; AnotB = 1; break;
case 27 : submod = 0; AnotB = 0; break;
case 28 : submod = 2; AnotB = 0; break;
case 30 : submod = 1; AnotB = 1; break;
case 31 : submod = 3; AnotB = 1; break;
case 35 : submod = 2; AnotB = 1; break;
case 40 : submod = 1; AnotB = 0; break;
}
#elif defined NANO54415
switch(pin){
case 13 : submod = 3; AnotB = 1; break;
case 15 : submod = 1; AnotB = 1; break;
case 16 : submod = 3; AnotB = 0; break;
case 31 : submod = 0; AnotB = 1; break;
case 33 : submod = 0; AnotB = 0; break;
case 35 : submod = 2; AnotB = 0; break;
case 37 : submod = 2; AnotB = 1; break;
case 39 : submod = 1; AnotB = 0; break;
}
#else
#error PLATFORM NOT SUPPORTED
#endif


sim1.mcpwm.sm[submod].init = startCnt; //Inital Value = -4096
if (AnotB) sim1.mcpwm.sm[submod].val[2] = pwmOn; //PWM_A On = -256
else sim1.mcpwm.sm[submod].val[4] = pwmOn; //PWM_B On = -256
sim1.mcpwm.sm[submod].val[0] = (reset-startCnt)/2; //Median 0
if (!AnotB) sim1.mcpwm.sm[submod].val[5] = pwmOff; //PWM_B Off = 256
else sim1.mcpwm.sm[submod].val[3] = pwmOff; //PWM_A Off = 256
sim1.mcpwm.sm[submod].val[1] = reset; //Final Value = 4096

InitializeModule();
}

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Thu Jun 13, 2013 12:06 am
by fd9750
Hi Everyone,

I could not get any internet for a day :( so I missed all of the replies, here is what I can say:

I am using the MOD54415-100.
I'll do some experimenting with pull-ups etc... Maybe it will make a difference.

As to outputs A & B: I have not used outputs B all by themselves but in my application A & B do work independently and in one of the PWM submodules A is the only one which is used.
All I can say is that, except for the different slew rate for PWM_B0, everything works great.

I use the 7 PWM outputs to generate various control signals for two CIS sensors, 6 Video speed AD converters and 6 FIFO RAMs, all working together.
In order to make it all work it is essential that each and every signal stays perfectly in sync relative to all of the others.
The PWM module is really good at that, the sync is perfect and although I regularly need to start and stop the PWM counting it stays that way.
I have used different processors and PWM generation systems before but this one is the best I have ever used. Very flexible, precise and well designed. Kudos for Freescale, they did a really good job.

I will need to provide buffering of the PWM_B0 signal anyway as it serves as the /WR signal for the 6 FIFO rams so it should not be to much of a problem. It is mainly a case of curiosity as to what might cause the different output behaviour.

if I find out more I will post it.

Re: Slew rate difference between PWM A0 and PWM B0

Posted: Thu Jun 13, 2013 3:10 am
by fd9750
Mystery solved,

One of the probes I was using to measure the signals appears to have become defective.
The result is that it presented a different load on the 2 outputs, very unusual but unfortunately **** does happen.

Using another one I get very similar results on both outputs so all is well in the world.

Too bad the probe did not just stop functioning altogether, I would have tried another one immediately.