glitch on PWM for servo signal

[chevy6600]

Hi guys, Can you help me with a glitch that i have in my servo signal I`ll try and keep this as short as possible.

I have put together 2 prototype circuit's with different power supplies capacitors etc. but with the same results.
I have run it through proteus (as per attachment) and it is predictable using software.
I have got myself a DSO oscilloscope which verifies what proteus predicts.
The flowcode program consists of code that produces a pwm signal using timer interrupts based on sean`s here in the forum.
The code is using only 2 of the signals for operating 2 servo`s. I have then added code to input 2 sensors using 2 ADC pins.

The object of the program is to modify these pwm signals using the data collected from the 2 ADC`s
together with my algorithms and a data file, the servo`s having end points programed together with a led to come on for each of the 4 end points.

Each servo output has its own chunk of algorithm.
So the situation is:
i am running a 18F2620 at 32mhz
with no algorithms the pwm is stable.
with 2 chunks algorithms servicing 2 pwm signals i get the glitch.
If i take away one chunk of algorithm i get a stable signal, although the pwm interrupts are still generating the 2 signals.

I have deduced from experimenting that if i slow the pic chip from 32mhz the glitch gets worse.
If i change the CCP1CON register to anything other than 1:1 prescale the glitch gets worse.
If i add a delay (using a `loop doing 255`) inside the macro that controls the interrupts, the pwm signal gets twice as long `but it does cure the glitch`. The trouble here is that the maths needed to correct the width of the pulse cause an over flow, as it appears that numbers greater than using 2 bytes would be required. The effect i get is, the pwm width can be slowly advanced but before it reaches an end stop it jumps back to the start, then carries on advancing before going completely crazy.

So from what i have gathered, i believe that the `ratio of time the interrupts use compared to the time used for the flowcode program `uses, needs to be changed in some form. I believe the interrupts cannot keep in step with the program completing, due to the fact that if half the algorithms are taken away the glitch is cured.

The size of my flowcode is not that large.
RAM available:3968 bytes, used:78 bytes (2.0%), free:3890 bytes (98.0%),
Heap size:3890 bytes, Heap max single alloc:127 bytes
ROM available:65536 bytes, used:2144 bytes (3.3%), free:63392 bytes (96.7%)

If i am right in believing that you are adding a pwm for use on servo`s in your update flowcode v4 this problem of mine is more than likely going to happen to your update when someone adds sufficient program code over a certain level!
So i would be grateful for any thoughts you may have on how to tackle this problem.

in the following picture of the oscilloscope, you will find 4 signals in 4 colours,
the green one not used.
the blue one is the led bulb that has come on, but does have a glitch at `B`
the red one is one servo, the `A` and `C`indicates the glitch.
the yellow is the other servo but still glitches.
Thanks in advance.

[Sean]

Hello,

I don't know the details of any changes you have made to the original program, so I will mention a few general points that influenced its design.

There are several potential pitfalls that the servo program must avoid.

1/ Using an 8-bit micro to manipulate 16-bit values with the possibility of interrupts occuring in the middle of the 2-byte read/write operations.

2/ The generation of two independent interrupt sources that act on the same outputs.

The original servo program avoids the first problem by only passing 8-bit values between the main program and the interrupt service routines (from the servo data and offset arrays). Conversion to the 16-bit values, and the loading of the compare registers, only occurs within the interrupt service routine - which can not be interrupted in this case. Integers can be used within the main program, and within the interrupt service routine, but should not passed between (as global values) them without additional protection/synchronisation mechanisms.
If the interrupt service routine tries to read an integer value from the main program there is the possibility of reading in the middle of an update, resulting in an integer consisting of one byte from the previous value and one byte from the next.

The second problem is avoided thanks to the properties of the servo signal. The minimum pulse width (provided by the fixed offset array values) ensures that there is a minimum of around 700us between the interrupt to turn a channel on, and the interrupt to turn it off again. If the offset array values are set correctly, the data calculations can only produce a maximum pulse width of 2.3ms, providing a minimum of 200us between the interrupt to turn the channels off, and the interrupt to turn the next channel on. In both cases there should be sufficient time to run the appropriate interrupt service routine (very comfortably) unless any time consuming operations have been added to them.
There could be problems if the calculations allowed the channel pulse value to be set close to zero, or close to the servo period value (not possible in the original program).

Another thing to remember when using integer variables is that they are signed. This can complicate the maths when trying to generate unsigned 16-bit values for peripheral registers.

There should be no problems with the relative timing of the interrupt and main program operation. If the servo program will read the necessary data from the arrays. If the main program has not updated the data between servo interrups, the previous value will be used again. If should not cause a glitch signal.

I hope some of this is helpful.

there should be no problems

[chevy6600]

Thanks for that sean, yes you have given me a lot to think about. I`m glad that the problem has a chance of being resoved. I`ll give my maths figures a going over.
P.S. does it still make sense that there is no glitch with half the flowcode code though?

[chevy6600]

Hi all, sean i have looked at my maths and to be honest they do not seem to me all that different from yours, i try to use single bytes rather than integers if for no other reason than to keep the coding small.
I have noticed that the glitch is effected by the movement of the potentiometer inputing to the ADC so i am wondering if it could be the ADC not being in step with the rest of the program, proteus does produce a notice stating that the `ADCconversion clock period is below the rcomended 1.6us` but it has always had this with good and bad behaving programs, and i have never found a method of extending some setting to eliminate it any way.
So could you please comment on any thoughts you may have, i have attached one of the many versions of my program just on the off chance that you may be able to spot some thing even if my code looks a mess.
thanks in advance.

[chevy6600]

Hi guys, well i was up late last night until the early hours and i believe that i have finally cornered the problem
causing my PWM glitch.
My program produces a PWM signal out putting to 2 servos, each servo having end stops programed and if an endstop is reached it switches on a Led light, the leds will dwell on for a short time. The PWM signals are controlled by sensors inputting to 2 ADC pins.
As i stated in my previous post, if i deleted half my code the program behaved better, well i took this a stage further by eliminating various bits of code adding other bits, etc. seeing what effect this would have on the glitch.

It transpired that when i removed the `output macros` in the flowcode which controlled the leds on and off the program WAS COMPLETELY STABLE which made sense as when i removed chunks of my code before, i removed the led `output macros` as well !!.
So taking this new found knowledge a step further i experimented with changing settings...outputting high/outputting low/using mask settings/using bite only etc...i have found out that if i output a `0` to the led or any other pin for that matter, the PWM signal would collapse ...not on every pulse but the occasional pulse, and when i setup the `output macro` to go `high` to a led or any other pin, the PWM signal would go HIGH as well!! not every pulse but the occasion one.

You can see both of these glitches in my picture of the oscilloscope in my previous post.
position `A` being the result of a `low` going output to some pin.
position `B` being the result of a `low` going output to some pin.( this pin is itself a led output)
position `C` being the result of a `high` going output to some pin.

It is interesting to note that when `high` going glitch effects the PWM signal it never cuts the pulse short ie. never interrupts the pulse in mid session... but causes the pulse to go high as soon as the pulse finishes...this low `spike` has got a width of about .02ms.
When the `low` going glitch effects the PWM signal, it does not keep the PWM signal from starting but pulls the signal down immediately it starts up.

MY DEDUCTION.
From all of this i think what is happening is that there is a clash of when switching the PWM outputs happen, clashing with other outputs being switched at the same time and for a fraction of a second there is an overlap of when various `bites` are all open at the same time on the port `C` and when the software code advances by masking of the `C` port the damage has been done...hence the glitch.

So i have got to the stage where i cannot take this any deeper/further as i believe the next stage would require digging in the workings of flowcode it`self which is where i hope you guys will take up the task.
I do know you are all snowballed under with work and you do not really want to take this on, so in my defence i would like to add that i believe that if you add `output macros` to your program versions using a PWM for a servo code, you will also get glitches...now i`m not a betting man but i would bet that if your upcoming flowcode v4 has a servo macro, that if any one adds any outputs they will get a glitching signal outputs and they will be on the forum here asking how to fix it. All the servo program designs that i have done in the past year can all be upset if i add outputs in the same way, i do not have time to design other circuits to put this to the test but i do think if you have some circuit designs to try you will get a glitch on the signal.

I will add that originally i intended for my program to control the signals together with various button inputs at start-up, to alter servo end stops on the fly, to adjust centre settings on the fly, led indicators for warnings , etc. All these extras i have had to remove because i found out when i used the EEPROM macro it too caused glitching, so the end product would not be able to remember new settings on the fly, and now it seems i will have to remove the led warning lights as well, and what i have left is just a PWM signal generator!.

here`s hopping that you will take on this challenge and have a dig into the flowcode program it`self to see if there is any millage in maybe altering your code to make sure these outputs do not clash.

A BIG THANKS in advance.

[Benj]

Hello Chevy

Good work for finding the root of the problem. That will help us a lot to get this under control.

When your outputting values to portC are you masking out the PWM pins eg in the output icon properties enable masking and leave the PWM pins unticked.

If you are doing this then please could you try the following C code in a C code flowchart icon.

clear_bit(trisc, 0); //Convert to output
set_bit(portc, 0); //Set pin high

where 0 is the pin you wish to change.

This will only work for a single pin but I can provide a multi pin workaround if you require it.

[chevy6600]

Hi benj, i`ll try what you suggest tonight, but i have tried using a mask to focus on a pin as well as using the idividual bit setting both gave the same result.

[chevy6600]

Hi benj, i have tried the `C` code you gave, good idea you had though, if i read you correctly you tried to eliminate the `masking` code out of the equation in the `output macro` but unfortunately it did not work.

I removed all the servo endstop led light outputs except one on bit `0` to apply your code.
In the led `output macro` (which is in a branch from the program loop incidentally) i set it up for masking, & unticked all bits. The PWM signal stayed stable until the led light came on.

I again tried the above but did not add your code to see if ALL the port pins stayed closed, of which they did. The led light stayed off and the PWM signal was stable. So the actual `output macro` sitting there is not it`self causing the glitch.

Incidentally i disconnected the actual led from the circuit in case i was getting some kind of back EMF but even if the pins are not connected to any thing they still glitch.....in ptoteus and prototype board.

your idea of eliminating the mask gave me an idea to try it on the PWM signal interrupt macro, the purpose of which cycles between 8 or in my case 2 output pins, putting a signal on one pin doing a program loop then outputting to another pin the next time around, the `output macro` using a mask for 2 pins is used. So i tried setting it up to only focus on one pin (signal was not usable...way off the correct time but fit for testing purposes). I unsellected all ticks in the mask to see if the signal was blocked.

I first tried it without your code. there was no signal. As expected it had blocked any signal.

I then used your code to allow a signal through. The signal got through as expected. This still caused a glitch using my program code setup as before when the led came on.

I then added more of your `C` code to the led `output macro` and the glitch appeared as soon as the led came on.

oh well, nice try though.

i do not know if you have seen it but i have attached one of my programs here in this thread it is on post 4 here.

[Benj]

Hi Chevy

Ok the fact that any I/O commands are creating a glitch on the PWM makes me wonder if this bug is simply present on the chips silicone.

I found a couple of topics on the subject.

http://forum.microchip.com/tm.aspx?m=93 ... PWM&#93430
http://forum.microchip.com/tm.aspx?m=84 ... PWM&#84563

Could be that you have to wait for the timer2 to rollover before writing values to the port register. I will try and look further into this when I get some time.

[Benj]

Hi Chevy

Ok Ive managed to find something a bit more useful now.

If the CCPx pin is configured as an output, a write to the port can cause a capture condition.

Taken from page 4 of the link below.

http://ww1.microchip.com/downloads/en/d ... 31014a.pdf

I havnt seen any workarounds at the moment but at least we can now see what is causing the problem.

[chevy6600]

Hi benj, that`s a great find. I must say that does look a good bet. but i`m afraid this part is a bit over my head, but i`ll help any way you think i can.
I have been playing around with my program, i have tried `setting` and `clearing` port bits with only `C` code that you gave, and placed them in different parts of my program to see if there was a difference, and also doing the same with the `output macros` , no luck though. I did find that one `output macro` outputting to a pin rarely gave a problem ( i would say no glitch really) , 2 outputs gave glitch once in a blue moon, 3 outputs was a bit more worse, and 4 was quite a regular glitch.....i have got 6 leds...1 power on...1 control flashing...4 servo endstops....using six outputs didn`t seem any worse than 4.
Thanks.

[chevy6600]

Hi benj, i have done a bit more digging, i have tried to clarify the program and my problem by changing the 5 pin outputs to use port `c` pin rc5, port `B` /0/1/2/4 , but NOT `B3` the ccp pin!.... This may be of interest if you think the ccp pins are involved. The purpose is to take the signal out of the equation because the glitch happens on any pin. ie. the other led outputs as well.

THE SETUP.
I have still got the servo signal program working in the background if for no other reason than to give the program sufficient size for the pic chip to `clock` through. I have 5 led outputs as above. The program cycles LED `RC5` on-off every 2000 program cycles = roughly 1 second on proteus. The other leds come on if the servo end points are reached, they go off when end points have not been breached.
The cycling led on `RC5` going on-off is the control, the other led or pin outputs are to see if there is any interference.

THE RESULT.
In the below oscilloscope picture i have zoomed into on an incident. I have 2 signals, the bottom green one is the controlled cycling on-off led going into it`s off state.
The TOP blue line is at a time when a servo (RB0) had breached an end point and left there, therefore it is showing a high of 5v output.

NOTE: when the green control led goes off as intended, the blue high output also goes low for a fraction of a second (not intended) which on my PWM signal would be my glitch. The width of the glitch can be seen to be 0.11ms (more accurate reading than i took before), this may be of interest as a `clock cycle rate` could be calculated which may be of interest, i myself do not know the maths to do this.
I have not been able to get it to pulse high though, so i think the glitch high i was getting before may of been just a function of a low going glitch with other factors involved.
Hope this helps.

[Benj]

Hello Chevy

Sean has just had an idea that may help.

For your port writes try using this alternative C code.

set_bit(latc, 0);
clear_bit(latc, 0);

where the output pin is portc and the output bit is 0. Replacing the portc register with latc may help to overcome the glitch that you are experiencing.

[chevy6600]

Hi benj, i have been trying out the code but initially it did not make any difference but it is work in progress as other parts of the program need to be altered / removed which may be giving me the glitch, so i will need the week end to fully test out all variations before a conclusion can be made on the use of the code....a few of the variations i have tried so far made a better improvement though ... I thought i would post up here now as you might like to know what the situation was before you left for the week end.

[Benj]

Hi Chevy

Ok thats great thanks for letting me know. Hopefully the lat registers will allow for the glitches to dissapear.

[chevy6600]

HI benj,
To start off, i have found an extra `output macro` some where in my program, i thought it was deactivated by using the `mask` and unticking all bits, so now i have deleted this in case it made a difference...... Strangely it did

I have now re run the various variations using the `output macro`, the ` ADC` components.
selecting ports by using `C` code " clear_bit(trisc, 0); set_bit(portc, 0);"
and lastly also using the `C` code, set_bit(latc, 0); clear_bit(latc, 0);
The 2servo signals program working with NO leds or OTHER port outputs programed in. RESULT: = steady pwm signals. NO glitching.
I first added 2 `output macro` components to output onto port C, RC0 & RC1, but setup not to output anything, this was done by selecting mask and unselecting all bits. Note also that i have NOT got a port/led pulsing every other second. RESULT: = GLITCHING PWM signals, and as expected no leds come on. Why it has a glitch in this setup is strange as it should be the same as not adding any `output macro` at all

I then activated the mask. Same setup as above but selecting bit0 and bit1 by `ticking` them on the mask. The RESULT: = glitching on PWM signals. 2 leds also come on and stay on as there is no program code to switch them off yet.

REPLACE WITH `C` CODE.
I then DELETED the `output macros` and replaced them with `C` code, `clear_bit(trisc, 0); set_bit(portc, 0);` and a similar one for the other output, `clear_bit(trisc, 1); set_bit(portc, 1);` the RESULT: = NO GLITCHING. Two leds come on as the servos reach there endpoints but stay on as there is no code to switch them off yet.
I then, using `C` code, added a led to go on and off every other second (proteus time) by doing 4000 program loops before toggling the led on/off. Also added more `C` code to switch off the servo-end-point leds to go off with the pulsing-one-second led when it goes off. This result: = NO GLITCHING.

CONCLUSION
It would appear that the glitching problem is now resolved by using the `C` code, although i tried this earlier on and found it still glitching, this was likely due to the extra `output macro` found amongst the program code, even though it was deactivated.
It would appear that because the `output macro` just sitting amongst the program code can cause the glitch and NOT what it actually does, is the culprit.

USING THE `LATC` `C` CODE.
I replaced the `C` code `clear_bit(trisc, 0); set_bit(portc, 0);` with the `set_bit(latc, 0); clear_bit(latc, 0);`.What i found was, the port would not come on unless i used the `clear_bit(TRISC, 0); before the `set_bit(latc, 0);`
Q. is this correct?

Another strange observation is: I have a small `macro`, it contains a normal `output macro` that flashes a led 5 times to come on BEFORE the main program loop starts, it only runs this once and is never used again, it indicates the device has been switched on. The strange thing is, i DO NOT NEED to use `C` code, `clear_bit(TRISC.0) before i use the `set_bit(latc, 0);` even though this part of the program is way into the main program loop.
The other `latc` port bits i still have to use the associate `trisc clear` `C` code.
Q. would you expect this to happen

Using the `latc` `C` code also RESULTED := in NO GLITCHING on PWM signals.

I have tried the alterations to my program on the actual pic 18F2620 -all be it on one servo-and it works great. So i will now finalise my program, then blow the pic chip, test, and let you know how it turns out.

I don`t suppose the `output macro` can be sorted out with the `C` code correction could it ...be good to have in the flowcode v4!

P.S. I think that i am going to go down in history to be the first person to wear out a pic chip by programming the chip too many times.
How many times does that take .....10,000......100,000. I have to be close by now.