1 2 Previous Next 21 Replies Latest reply on Mar 19, 2015 10:31 AM by helic_263931

    PSOC5LP Jitter in interrupt handling




      I am just starting with CY8CKIT-050 Development Kit.


      I am using two SAR-ADC (Sampling frequency 100 kHz) and some time-critical calculation in a hight priority interrupt service routine (prio 0). Everything works fine until I implement an additional interrupt service (rising edge @ 10Hz, priority 7) to set a flag for further processing. This further processing is done in den main-loop and sends some data to the display.


      When the the low level interrupt is enabled, I measure a Jitter (about 1.3us) in the signal processing in the high-priority interrupt service routine.


      This is done with a toggle Bit as digital output at the end of the routine. The service routine is triggered by eoc of one ADC and needs about 4 us for the signal processing (without code optimization).


      The reason for this Jitter is the code in the main loop (LCD functions) :


        Disp_Flag = 1; 


      int main(void) .....


               if (Disp_Flag == 1)
                  // Doing nothing for testing!
                  phi_disp = (phi_LUT_int * (uint64)360000) >> 16; // für P = 2
                  sprintf(displayStr,"%4d %4d ",(int)voltCount_sin,(int)voltCount_cos);
                  result = sprintf(displayStr,"%6d mGrad",(int)phi_disp);
                  Disp_Flag = 0;


      There is also a Jitter in the signal processing, depending on the input signal values and the adjustment of code optimization. But with constant input values (ignoring the ADC-Data) this jitter is not existing.


      Could you give me some hints for solving this problem? 


      with regards



        • 1. Re: PSOC5LP Jitter in interrupt handling

          Welcome in the forum, Steve_c!


          The only idea I've got concerning the jitter has to do with the CPU internal handling of interrupts: When a handler finishes and returns from interrupt a check is made for any interrupt pending. If so, the call for the next handler is shortened (ARM tries to save cycles). This may cause some jitter depending on whether the isr_disp interrupt occurs during execution of your ADC_COS_ISR_LOC-handler or out of that time.






          PS: I am located near Bremen, where do you live?

          • 2. Re: PSOC5LP Jitter in interrupt handling

            Hello Bob,


            thank you for the fast answer.


            The high priority interrupt handler interrupts in most cases the loop in main() and rarely the very short low priority interrupt handler.  I measure the jitter by triggerung a oscilloscope with the sample_clock (soc of ADC) and looking at the time behaviour of the toggled digital output.  If I toggle the digital output directly at the begin of the high priority interrupt handler, the jitter is much smaller. So there is an additional jitter in the processing of the high priority interrupt handler. 


            This looks like an interruption of this handler, which should not occur, because there is no interrupt-source with higher priority.


            The context switch by the interrupts shouild be done in about 12 cycles (@ 64 MHz less than 200ns), or?






            PS: I am living in Wetzlar, 50 km north of Frankfurt

            • 3. Re: PSOC5LP Jitter in interrupt handling

              The code you are using in the ISR looks like ?




              Regards, Dana.

              • 4. Re: PSOC5LP Jitter in interrupt handling

                Hello Dana,


                I attached ther code in the first posting.


                But here is the summary for the high priority handler:


                    int16 x,y,z; // and someother local  variables
                   // reading the ADC-samples   


                   x = CY_GET_REG16(ADC_COS_SAR_WRK0_PTR)-2048;
                   y = CY_GET_REG16(ADC_SIN_SAR_WRK0_PTR)-2048;
                    // doing some calculation
                    // filtering, division, table look up for atan-Interpolation
                    // writing a result in a Control Register
                    // writing the toggle bit directly
                    Pin_Period_DR  = (Pin_Period_DR & 0xBF)| period;
                    // toggle the bit for the next cycle
                    if (period == 0)
                      period = 64;  // direct the right bit position
                      period = 0;


                I placed most signal processing in the ISR to handle the not time-critical processing in main().





                • 5. Re: PSOC5LP Jitter in interrupt handling

                  I would see what you are seeing is a caching effect. The PSoc5LP has a 128 byte instruction cache. If only your ISR runs, its probably fully cached and can run with full speed any time. If the main loop does something (every time Disp_Flag==1) it gets loaded into the cache, and the ISR runs a little bit slower since it sees cache misses. That also explains why the jitter is better when toggling the flag at the beginning of the ISR - there you have less cache misses to handle and the delay is shorter.


                  (from the TRM, table 5-1: the instruction fetch time from memory is up to 4 clock cycles)

                  • 6. Re: PSOC5LP Jitter in interrupt handling

                     From a very high level point of view, there are a few  things you can do to avoid the jitter.  Pick one or none, your choice!


                      1) enable interrupts in your low priority ISR at the beginning. This will reduce jitter, but it should make it much less than a microsecond.


                     2) Process the flag test at the end of the high priority ISR as an afterthought, if the timing of the event allows.


                      3) use your low priority input to set a Set Reset Flip Flop that feeds a control register.  Read the control register in your main loop, and reset the FF via software in your main using a control register.  If your FF is set, process it the same way you would have done with the flag set in software.


                      4) Depending upon what you need to do software, design some hardware to do an output that you need for the high priority event and process the event's information in your software a bit later, in an ISR that can stand some jitter without upsetting the apple cart.


                      5) If this is a periodic event, and can stand one event's delay, consider allowing the information to go out one event later.  the ISR can jitter, but set up for the next output event that occurs on a clock (i.e. your input signal that triggers the isr).

                    • 7. Re: PSOC5LP Jitter in interrupt handling

                       One more thing, if the output bit can always be offset a couple of microseconds without issues, you could use a 2us clock into a flip flop synchronizing pair and set or reset the D line.  It would then set/reset 2us later with no "jitter" seen on a scope.

                      • 8. Re: PSOC5LP Jitter in interrupt handling

                        Excerpt from ARM Cortex M0 Generic User Guide


                        "Tail-chaining This mechanism speeds up exception servicing. On completion of
                        an exception handler, if there is a pending exception that meets the
                        requirements for exception entry, the stack pop is skipped and
                        control transfers to the new exception handler.
                        Late-arriving This mechanism speeds up preemption. If a higher priority
                        exception occurs during state saving for a previous exception, the
                        processor switches to handle the higher priority exception and
                        initiates the vector fetch for that exception. State saving is not
                        affected by late arrival because the state saved would be the same
                        for both exceptions. On return from the exception handler of the
                        late-arriving exception, the normal tail-chaining rules apply."




                        Nothing to do with the jitter, but the variable Disp_Flag should be declared as "volatile" or you will get a bad surprise when compiling with build option "Release".





                        • 9. Re: PSOC5LP Jitter in interrupt handling

                          The output of the high priority interrupt handler is written to a control register which is in Sync-Mode with the sample_clock for the further signal processing in hardware.


                          So the Jitter is at the output not visible. The problem is, that the Jitter reduces the maximum possible sample frequency or the available time for some more signal processing in the ISR.


                          That´s the reason I want to understand the reason for the Jitter.


                          The next step to proceed  is to measure Cache Hits or Misses. Does anybody has some sample code for this topic?


                          ...and to declare Disp_Flag as volatile ...


                          Is there an influence on the timing from the debug mode instead of the release mode ?

                          • 10. Re: PSOC5LP Jitter in interrupt handling

                            One question: why are you concerned about the jitter? It seems there is a low (or even non-existing) jitter at the start of the ISR, but the execution times differs. But I don't see anything in the ISR that is timing-critical.


                            It might be better, in the long run, to use DMA with two buffers per ADC, ping-pong between them and then do mass-data processing whenever one of the buffers is filled up. That way you don't need to do any long-running calculation in an ISR (which is a bad practice anyway)

                            • 11. Re: PSOC5LP Jitter in interrupt handling

                              (Oh, you answered my question while I was writing on it :)


                              I'm not sure how easy it is to measure cache misses, I'm not aware of something like performance counters in the Cortex-M3 cores. Looks like you will need to read up the available ARM documentation...


                              Release mode is faster than Debug mode, since the compiler is able to do much more optimizations.

                              • 12. Re: PSOC5LP Jitter in interrupt handling

                                You have jitter in the code due to the "period" test/assign


                                code, so possibly move this outside ISR if you can. Or


                                write in asm and equalize the used cycles with NOPs.


                                One would have to be concerned with compiler optimization


                                in ASM (if there is any, of this I am not sure).




                                You might confirm this by looking at .lst file and counting instruction






                                Regards, Dana.

                                • 13. Re: PSOC5LP Jitter in interrupt handling

                                  I don't think so. a) the port toggle that steve is using to determine the jitter comes before the test condition, and b) the jitter only happens when the main loop does something meaningful (updating the LCD).

                                  • 14. Re: PSOC5LP Jitter in interrupt handling

                                    Yes, changing only one code line in the main loop results in a jitter of about 1 us!

                                    I have done some measurments (.pdf attached)

                                    The Code is now compiled with the optimization set to speed, but this changes nearly nothing in the amount of jitter.

                                    The optimization works fine: The time for the signal processing is reduced to about 1.8 us due to a better utilization of the cpu registers.


                                    I increased the sampling rate to 200 kHz.


                                    There is no change between debug and release version.

                                    With only one code line in the main loop, there is no jitter at all!:

                                    if (Disp_Flag == 1)
                                                 phi_disp = (phi_LUT_int * (uint64)360000) >> 16; // für P = 2
                                                 Disp_Flag = 0;

                                    Adding one code line results in a jitter of about 1 us:

                                     if (Disp_Flag == 1)
                                                phi_disp = (phi_LUT_int * (uint64)360000) >> 16; // für P = 2
                                                sprintf(displayStr,"%4d %4d ",(int)voltCount_sin,(int)voltCount_cos);
                                                Disp_Flag = 0;

                                    1 2 Previous Next