hw_timer frc1 with reload mode false and CLKDIV_256 causes WDT (GIT8266O-664) #1086
Comments
github-actions
bot
changed the title
|
I removed a my wrong comment. Sorry for the inconvenient. |
|
No problem,
Do you have any suggestions?
I would even offer to fix this, but I am not too familiar with the internals of this OS. But I worked on VxWorks RTOS for many years at Nortel. Is there any docs that you could link to me that could help me figure out how to debug this?
Btw, I know this design pattern, ie: sending a msg from the ISR, works great on my Esp32/idf.
Jerry
On Apr 27, 2021, at 12:58 PM, dsptech ***@***.***> wrote:
I removed a my wrong comment. Sorry.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#1086 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACTU53A7AFBXM6CF4XFLFF3TK3ULJANCNFSM43RWZOWA>.
|
|
I'm interested to this issue so I've already tested the frc1 timer using the same conditions (using with a very simple handler) ... and I seen that the timer work properly. Regarding your issue, the debug log you produced suggest that your msgTask is looping with no waits for an unknown reason (and this task starve the idle task, so the watchdog clear cannot occur). I suggest to test the timer only as first pass (and to strip out all rtos related), for example: P.S.: Search for documentation related to this SDK is .... a very big deal. The link https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/ is incomplete, so I use multiple sources as the ESP32 docs (you can find here some debug info), ESP8266 arduino docs, the Espressif forum, the freeRTOS website and other resources over internet, but in my case the most useful tool is Eclipse that allow to find everything in the SDK source code and inspect inside that. |
|
Good idea. That test reveals some very interesting information. However, with hw_timer_set_reload(false) and a 10s delay - the cbCount value is 2900484 for example. (see the not working log below). So I guess this is why the message queue code blows up. The ISR is firing too much and overflowing the queue. Working Log: Not working Log: |
|
Strange, this work to me instead.
|
|
Hi, This is the output: |
|
STOP ALL!! The issue is clock frequency related. Previous tests are performed at 80Mhz. |
|
It appear like a timing issue of the hw_timer_isr_cb() function (see hw_timer.c) or a buggy hardware. As fast workaround, I placed the code below at the bottom of the your callback function (this wipe out the timer configuration): Note: for a fast configuration, you can save the frc1.ctrl.val value immediately after the timer activation and write it to restore the full configuration and activate the timer again. Hi @donghengqaz, sorry to bother you. Have you some related info ? |
|
@dsptech I believe that I have found the problem. |
|
@dsptech finally have time to report back. I also made some small changes in the hw_timer.c to account for this in the hw_timer_set_clkdiv() and hw_timer_get_clkdiv(). But it doesn't help. It makes no difference at all in fact. So back to some other questions you had earlier:
And log output for reload(false) case: |
|
Hi, In my previous tests, I found that the issue it is likely timing related (or there is a hardware bug inside the timer). For example, I changed the function hw_timer_isr_cb() with the following function (swap of the two "if") and now the timer appear to work. I don't know the true reason. |
|
@dsptech - I tried that change on my NodemcuV2 board, and it's not working for me. I still see the cbCounter incrementing to a large numbers (like: 2595076). :-( |
|
|
This patch also seems to work: |
|
The 1st patch works on my board. The 2nd patch does not work on my board. |
|
I need to investigate again about the 2nd patch. my thoughts:
|
|
P.S.: you can strip strip out "soc_clear_int_mask(1ul << ETS_FRC_TIMER1_INUM);" from the first patch. |
|
Hi, I found no other way than the first patch (with the constraint of not altering the timer configuration), but I worked out the patch a bit. This new patch will speed up the timer instead of waiting for its natural underflow: |
|
Hi @dsptech this patch 3 also works properly for me on my board - nice! |
|
Hi, If we disable the timer, but the counter still has zero value, the above issue will occur so a preventive correction is required. This is expected only for prescaler = 256 with very fast user callback functions. If enough time is elapsed (slow callback functions) an underflow is already happened and the counter already has the value = 0x7FFFFF (or slightly lower due the elapsed time). In this case no correction is needed. This is also the normally expected condition. Note: The 3rd patch is fully operative but it has a big code footprint due the concurrent volatile accesses and bit fields managements. I already written a more lightweight patch and actually I'm testing it. I need to be sure about the write timings. |
|
Hi @jvh003, This is now the optimized patch I actually testing: In this version, the "control" section has an half sized footprint (inspection on disassembly) against the previous patch due the removing of some not required access to volatile bitfields. |
|
hi @dsptech. |
|
Hi @jvh003, The above issue means that:
Moreover, the NMI (pwm driver) can shot anytime causing further issues about the timing. For these reasons a different approach is required. (Hopefully this is the latest patch to test) |
|
Hi @dsptech. Yes, this is sort-of-what I was trying to get at before when I asked the question about the: if (frc1.count.val == 0) check. Anyway, glad to see you tested it and found some other problems and then figured it out. |
|
Hi @jvh003 I'm still testing the patch but I will remain a bit concerned that the workaround is due an undocumented hardware "bug" and works due undocumented hardware "features". |
|
Hi @jvh003, The PR does not include the fix about the register layout, but I already fixed it (as you already done too) and a pair of functions were added. Any suggestion is appreciated, so if you wish to give a look you can find the work here: |
|
Hi @dsptech. I looked the PR. Looks good to me. |
|
Not sure if it is still of interest, @dsptech, but the The ... which previous was 4 and 8, now becomes 1 and 2. And that will lead to the I think this will fix it: |
Environment
Problem Description
Trying to use the frc1 hardware timer with CLKDIV 256 in single shot mode to set a delay of 20s. My test interrupt service routine enables 2 GPIO pins for debug, and also sends a message to a message queue.
Changed my test code to use a 1s delay for testing.
As a small (minor) thing I also noticed while try to work on this:
The comment on line 27 in timer_struct.h is in-correct.
The FRC1 is a 23 bit timer, not 24 as stated in the include file.
Expected Behavior
After 1s the interrupt service routine should fire, turn on the 2 GPIO pins, and send my test msg to the queue. See function hw_timer_callback() below.
This timer should work in either reload true or false mode.
Actual Behavior
This timer only works properly in reload true mode.
If the reload mode is false:
Steps to repropduce
Load the code and run it.
The code was modified from the example code found here: hw_timer_example_main.c
However, since I wanted to code up a larger delay ie: 20s, I modified the example to explicitly call all the hw_timer functions that the function hw_timer_alarm_us() was calling internally. (see below).
Code to reproduce this issue
Debug Logs
Logs for the code running the timer in reload true mode.
This is the expected output.
These are the logs for the code running in reload false mode with the WDT:
Other items if possible
Let me know if you really need/want the sdkconfig or ELF file.
The text was updated successfully, but these errors were encountered: