Project

General

Profile

Forums » Req. WJ2(ESP32) support »

Timer precission

Added by Panagis Vovos over 3 years ago

Hello there,

This is a synchronization/timing question wrt timer interrupts.
If you wait 1-2 hours while a timer interrupt executes in a code, you will see there is a difference between when an action is supposed to happen with the timer interrupt and when it actually happens. Unfortunately, this is not "cured" by the lower interrupt rate; it is just happening with a slower pace. Besides, there doesn't seam to be an error message on the serial monitor (e.g. "rate too fast").

I have prepared a stripped down version of my Simulink file that focuses only on the actual timing issue. What it does is simple: A timer is set to tick every 0.001s with the prescaler set to 2 (so that the time interval can be calculated exactly to 0.001s). Every tick enables a function that switches on the GPIO2 led (onboard my Devkit v3) every 1 minute for half a minute (30s on – 30s off etc). Please notice that I do use a “compatible” time interval for the clock interrupt. However, every 10 minutes that pass the led switches on ~1s later than it should, so, for example if you leave the code running on the board for 30 minutes, you will have the led switched on 3s later than it should. If you decrease the timer interval, for example to 0.01s you will have to wait for 30 minutes to clearly notice the delay (~2s). If you make it faster, you will notice it earlier.

I used my stop-watch to measure those differences, as the time is gigantic for any oscilloscope. However, the difference IS there, even if I cannot measure it precisely with a stop-watch.

I think the problem is indifferent of the 0.001s limitation. It looks like it is reversely proportional to the time interval, BUT certainly has nothing to do with the ticking precision of the 40 MHz crystal, which is 1000X better according to espressif (even in the worst case).
Let me ask:
a) Is there is a chance that the timer interrupt is set every sample time(!) and then the board waits for the next interrupt etc, so this adds a small delay every time it is run?
b) If I look under the mask of the clock interrupt block I can see a "timer_pause" variable, but I cannot see the value it has in the code. Does this have anything to do with it?
Thanks,
Panagis

Crystaltest.slx Crystaltest.slx 31.1 KB

Replies (11)

RE: Timer precission - Added by martin van beek over 3 years ago

Hey Panagis,
Grabbing the time deviation is no problem for my oscilloscoop ;o)))
But you've right, the timing is not as expected in this current simulink model.
See for the result the pictures attached.
Kind regards,

Martin.

Capture_time10minutes_1second_deviation.JPG View Capture_time10minutes_1second_deviation.JPG 126 KB
Capture_time20minutes_2seconds_deviation.JPG View Capture_time20minutes_2seconds_deviation.JPG 129 KB
Capture_time30minutes_4seconds_deviation.JPG View Capture_time30minutes_4seconds_deviation.JPG 129 KB

RE: Timer precission - Added by martin van beek over 3 years ago

I've add a subsystem that toggles every 30 seconds sharp an output pin, the red line of the oscilloscoop.
The blue line is the output pin of the triggered Interrupt Service Routine.
When zooming in, you will find out that the timing of the ISR isn't correct, the deviation over 30 minutes is almost 4 seconds and needs to be investigated.
See for details the attached pictures.
Kind regards,

Martin.

Capture_time10minutes_1second_deviation_mvb.JPG View Capture_time10minutes_1second_deviation_mvb.JPG 422 KB
Capture_time20minutes_2seconds_deviation_mvb.JPG View Capture_time20minutes_2seconds_deviation_mvb.JPG 407 KB
Capture_time30minutes_4seconds_deviation_mvb.JPG View Capture_time30minutes_4seconds_deviation_mvb.JPG 439 KB
Crystaltest_2018B.slx Crystaltest_2018B.slx 30.3 KB

RE: Timer precission - Added by Dhanika Mahipala (ดานิก้า) over 3 years ago

Hello Panagis and Martin,

Thank you Martin for this information. We are currently investigating this issue. We would get back to you soon with a solution.

Dhanika

RE: Timer precission - Added by Panagis Vovos over 3 years ago

Thank you Martin for your detailed analysis.
Dhanika, would you consider the possibility that the timer is set at every sample time, instead of just once? I do not know why this may happen looking at the created code from Simulink, but the delay fits this assumption, more or less.

Thank you for your effort,

Panagis

RE: Timer precission - Added by Panagis Vovos about 3 years ago

Dear Dhanika,

It has been more than 2 weeks since you have started investigating this issue. I know it is a busy period. However, could you please inform me if there has been any progress, please? I am in full standstill due to this problem.

Thank you,

Panagis

RE: Timer precission - Added by Dhanika Mahipala (ดานิก้า) about 3 years ago

Dear Panagis,

Thank you for your patience. We are currently working on a few other projects. We will be looking into your issue as soon as possible.

Regards,
Dhanika

RE: Timer precission - Added by Senal Ranaweera (เซนัล) about 3 years ago

Dear Panagis,

Sorry for the delayed response. It took some time to find the root cause of the problem you requested. It was a bug in the timer Interrupt block.
For the testing purpose, I have used the same model file Crystaltestprev.slx you attached.

Before testing out the above model please replace the following patch file, esp32_timer_interrupt.tlc at the location:
" [ your path to waijung2 installation directory ]\waijung2_20.11b\waijung2\targets\esp32\src\blocks "

Regards,
Senal

esp32_timer_interrupt.tlc esp32_timer_interrupt.tlc 7.99 KB
Crystaltestprev.slx Crystaltestprev.slx 29.7 KB

RE: Timer precission - Added by Panagis Vovos about 3 years ago

Dear Senal,

Thank you for your reply and, mostly, thank you for your time and effort to fix the bug.
I have set the timer interrupt to 0.001s (counter 0-59999) and, indeed, there is only a -0.5s drift in 3 hours of runtime. So it is fixed there.
When I set it to 0.0005 s (counter 0-119999), there is a negative drift by -1s after 3h. Again, you can consider it more than acceptable.
However, when I set it to 0.0001s there is a positive drift by +84s in 3h!
Please, notice that both last tests, did not result to an error at the monitor, which means that the interrupt routines called had enough time to execute.
How is this excessive overhead explained in the last case though?

You can find the detailed settings below.

Interval: 0.001
Alarm: Enable
Alarm Mode: With Reload
Counter: 0-59999
Counter Direction: Up
Led On: Counter>29999
Drift: 3h > -0.5s
--------------------------------
Interval: 0.0001
Alarm: Enable
Alarm: With Reload
Counter: 0-599999
Counter Direction: Up
Led On: Counter>299999
Drift: 3h > +84s
--------------------------------
Interval: 0.0005
Alarm: Disable
Alarm: With Reload
Counter:
Counter Direction: Up
Led On: Counter>59999
Drift: 3h > -1s
--------------------------------

Thank you,
Panagis

RE: Timer precission - Added by martin van beek about 3 years ago

Hi Senal,
Can you give us more background information about the root cause of this time deviation.
When I look into the solution you provide, you only did a small timing subtraction adjustment, (1.4 * (TIMER_BASE_CLK / TIMER_DIVIDER)/1000000).
Looking forward to your response, kind regards,

Martin.

RE: Timer precission - Added by Dhanika Mahipala (ดานิก้า) about 3 years ago

Dear Panagis,

The error could be due to an API version problem. However I re-created the esp32_timer_interrupt block with a few modifications. Please download the ZIP file attached and follow the steps below to install the block to your current waijung2 installation.

1. Close Matlab (which the waijung2 is installed in) if it is running.
2. Unzip the attached file (esp32_timer_interrupt_block_patch.zip) and copy and paste the content to replace the files, esp32_io_lib.slx, esp32_timer_interrupt.mex, esp32_timer_interrupt.tlc, esp32_timer_interrupt_callback.m at the location,

[ your waijung2 installation directory ]\waijung2_20.11b\waijung2\targets\esp32\src\blocks

3. Restart Matlab and use the model file attached (timer_interrupt_block_testing.slx) file to test the said block.

Please let me know whether the new block performs as expected.

Here are the attachments mentioned,
  1. Patch file for the block - attachment:esp32_timer_interrupt_block_patch.zip
  2. Model file to test the the new block - timer_interrupt_block_testing.slx

Regards,
Dhanika

timer_precision_test.zip timer_precision_test.zip 1.96 KB
timer_interrupt_block_testing.slx timer_interrupt_block_testing.slx 29.7 KB

RE: Timer precission - Added by Panagis Vovos about 3 years ago

That is what I call "support" Dhanika!

Excellent work. I have collected some data from my tests with the new patch in place. Indeed, things work as expected now (according to the C code as benchmark).0There is about 1.5s delay in 10 h of execution for 0.001s triggering and 1.5s in 1h of execution at 0.0001s triggering of the interrupt.
The conclusion is that the delay in seconds seems to be proportional to the interrupt rate. However, it looks like it is not perfectly "constant" as we initially thought. If it was constant then in would add X time to each interrupt, which would give a delay in tenths of seconds for the 0.0001s triggering. That actually WAS happening before your latest patch (I got 84s at 0.0001s triggering).

I believe this is the best we can get out of this crystal after all. However, that is not that bad (i.e. it works for most power converter applications) and a control system is needed to cover any discrepancies, anyway. However, in order to have such a balance between control and actual execution I have to specify the core that this fast-triggered piece of code is executed, so the rest (e.g. control) works undeterred at the slower rate. But I will open an appropriate, new ticket with that one, and hopefully you will contribute you magic on this one as well ;) To be honest, that would be the last step to make Waijung2 THE tool for educational power converter applications with a board available to practically everyone (ESP32).

Once more, congratulations and thanks a lot,

Panagis

    (1-11/11)