Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Parallel processing of pwm and comparator

Status
Not open for further replies.

electronicsman

Full Member level 5
Joined
May 4, 2012
Messages
291
Helped
11
Reputation
22
Reaction score
12
Trophy points
1,298
Activity points
3,737
I am facing this problem. I have configured my pwm for 20khz and implementing the logic of space vector modulation in the interrupt routine in pwm interrupt. The problem is the hall sensors are analog and given as input to comparator of controller to convert to digital. But sometimes i am finding that controller is missing to generate the pulses in between and randomly around one hall change. Is it because of the high frequency of the pwm interrupt? The micro is dspic33ev256gm106.
 

Opposite. If you change duty value on slow frequency, you should take to account that fact, that sometimes one pulse can be skipped. The solution is to reset the counter each time you change duty cycle.
 

I would suggest to check with an oscilloscope the comparator reference voltage and its output. Also check PWM output on another channel.
 

Hi,

usually the PWM is generated by hardware and doesn´t necessarily need to run an ISR.
At least not at every single pulse. An ISR - especially with "C" needs some software overhead and thus it takes some processing time.
But you should confirm that the duty_cycle_setup is updated only when the counter = 0 (or on TOP).
Some microcontroller do this automatically, with others you need to do this in an ISR - only when the duty_cycle changes.

Klaus
 

The observation i made after seeing the waveform was that the comparator output was not exactly giving the high or low at exactly the cross over point. Randomly it was introducing some delay. I observed that the interrupt flag is not cleared immediately after entering the interrupt but at the end after some processing and this solved the varying delays. But one issue still remains there is a fixed delay of around 30 micro seconds of interrupt latency. How to reduce it?
 

If you have concurrent interrupts (e.g. hall sensor and 20 kHz pwm tick), you also get varying latency according to interrupt procedure execution time. Estimating or measuring the execution time it could be a first step.

To me it look like a not well-considered application layout. How about dropping concurrent interrupts and sampling the hall signals in 20 kHz (or even faster) periodical interrupt?
 

I followed mostly the micro chip application note where it is almost implemented the same with pwm at 20khz and the hall sensors are connected to the Change notification inputs, in my case it is the comparator inputs. My doubt is interrupt latency time. As per the data sheet this time is fixed. I agree that i am doing lot of processing in the ISR but i have given the highest priority to the comparator or hall sensor interrupt, so it should be coming back to the comparator interrupt without delay is my guess even it is executing some other interrupt. Two questions before i really rewrite the code

1. Is the interrupt latency is fixed (even with small tolerance)?
2. Does the interrupt latency also depends on the code size of the ISR? Please advise.
 

The latency of the highest priority interrupt should be small (< 1 µs). Seeing 30 µs latency means there's something wrong in your code. Either the respective interrupt has not the highest priority, you have disabled nested interrupts or your code disables interrupts intentionally for extended time intervals.
 

Very inportant:
In your micro dspic33ev256gm106 the highest CPU Interrupt Priority Level is 0. Have you given level 0 to the comparator interrupt?

But one issue still remains there is a fixed delay of around 30 micro seconds of interrupt latency. How to reduce it?
From the datasheet I know that there is a Fixed Interrupt Entry and Return Latencies.
I have got the following questions:
1. What is the clock frequency?
2. Do you use power saving modes? I ask because in yours micro's datasheet is a chapter "INTERRUPTS COINCIDENT WITH POWER SAVE INSTRUCTIONS".
3. How did you measur this 30 us? You have a comparator output signal change as a start time moment. What event do you treat as an end time moment? One of the options is to set one GPIO pin at the very beginning of the ISR. If you followed this method, what instructions are before GPIO set?


...it should be coming back to the comparator interrupt without delay is my guess even it is executing some other interrupt.
Three very different things were mentioned:
* interrupts prioritization - double check if your interrupts have appropriate priority,
* nested interrupts - check if bit NSTDIS in INTCON1 register is 0,
* context switching - check how many clock ticks your micro needs to change the context.

Two questions before i really rewrite the code

1. Is the interrupt latency is fixed (even with small tolerance)?
2. Does the interrupt latency also depends on the code size of the ISR?
How do you define interrupt latency? Your micro has Fixed Interrupt Entry and Return Latencies. If you define interrupt latency as the time when your micro fully handles the interrupt - then yes, it depends on what instructions are in the ISR.
 

Hi,

What about
* inserting some debug instructions into your code (set port high/low)
* posting this code
* posting your schematic
* posting some scope pictures with pwm, hall signals, debug signals

Klaus
 

Very inportant:
In your micro dspic33ev256gm106 the highest CPU Interrupt Priority Level is 0. Have you given level 0 to the comparator interrupt?
.
No level 7 is the highest priority.
 

No level 7 is the highest priority.
This is correct - level 7 is the highest.
From dsPIC33/PIC24 Family Reference Manual:
The usable priority levels are 1 (lowest priority) through 7 (highest priority).

Datasheet is misleading by IPL3 and IPL<2:0> descriptions and values in parentheses:
IPL<2:0>: CPU Interrupt Priority Level Status bits(1,2)
111 = CPU Interrupt Priority Level is 7 (15); user interrupts are disabled
...
000 = CPU Interrupt Priority Level is 0 (8)


Phrase "user interrupts are disabled" might suggest that interrupts are disabled for level 7 and 15.
 

Interrupt.png
As per the interrupt user manual i have seen as shown in the image. What is Mov.d instruction? When this will be introduced? Please advise.
 

Attachments

  • interrupts.pdf
    306.4 KB · Views: 71

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top