Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32S2 Timer Example crashes if timer_group_set_alarm_value_in_isr is not called (IDFGH-5229) #7001

Closed
stokmanis opened this issue May 9, 2021 · 6 comments
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@stokmanis
Copy link

I am trying to use the General Purpose Timers one time alarm on ESP32S2 by using the Timer Group example https://github.com/espressif/esp-idf/tree/639e7ad494d93fc82159f9fe854041bc43a96d5f/examples/peripherals/timer_group.
As the repeated alarm is not needed, I am commenting out the line
//timer_group_set_alarm_value_in_isr(info->timer_group, info->timer_idx, timer_counter_value);
But the program crashes.
Program is executed on ESP32-S2-Saola-1 development board.
ESP-IDF version 4.2.1
Here is the output of the crash

Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0).

Core 0 register dump:
PC : 0x400297cf PS : 0x00060034 A0 : 0x80026124 A1 : 0x3ffbd810
0x400297cf: xQueueGenericSendFromISR at C:/opt/esp-idf/components/freertos/queue.c:1189

A2 : 0x3ffc2fd0 A3 : 0x3ffbd838 A4 : 0x3ffbd830 A5 : 0x00000000
A6 : 0x3ffc3018 A7 : 0x00060023 A8 : 0x00000000 A9 : 0x00000000
A10 : 0x80000000 A11 : 0x00000000 A12 : 0x00060023 A13 : 0x3ffc2fd0
A14 : 0x00060023 A15 : 0x00000001 SAR : 0x00000020 EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000 LBEG : 0x00060023 LEND : 0x3ffc2fd0 LCOUNT : 0x40024ee4
0x40024ee4: xt_highint4 at C:/opt/esp-idf/components/esp_system/port/esp32s2/dport_panic_highint_hdl.S:58

Core 0 was running in ISR context:
EPC1 : 0x4009390f EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x400297cf
0x4009390f: uart_hal_write_txfifo at C:/opt/esp-idf/components/soc/src/hal/uart_hal_iram.c:35

0x400297cf: xQueueGenericSendFromISR at C:/opt/esp-idf/components/freertos/queue.c:1189

Backtrace:0x400297cc:0x3ffbd810 0x40026121:0x3ffbd830 0x40026b8d:0x3ffbd870 0x40025d0a:0x3ffbd890 0x40093623:0x3ffc2360 0x40082a1b:0x3ffc2380 0x400280a2:0x3ffc23a0 0x400279ed:0x3ffc23c0
0x400297cc: xQueueGenericSendFromISR at C:/opt/esp-idf/components/freertos/queue.c:1189

0x40026121: timer_group_isr_callback at c:\g\e3\test\esp\timer\build/../main/timer_group_example_main.c:69

0x40026b8d: timer_isr_default at C:/opt/esp-idf/components/driver/timer.c:216

0x40025d0a: _xt_lowint1 at C:/opt/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1105

0x40093623: esp_pm_impl_waiti at C:/opt/esp-idf/components/esp32s2/pm_esp32s2.c:479

0x40082a1b: esp_vApplicationIdleHook at C:/opt/esp-idf/components/esp_common/src/freertos_hooks.c:63

0x400280a2: prvIdleTask at C:/opt/esp-idf/components/freertos/tasks.c:3386 (discriminator 1)

0x400279ed: vPortTaskWrapper at C:/opt/esp-idf/components/freertos/xtensa/port.c:143

@espressif-bot espressif-bot added the Status: Opened Issue is new label May 9, 2021
@github-actions github-actions bot changed the title ESP32S2 Timer Example crashes if timer_group_set_alarm_value_in_isr is not called ESP32S2 Timer Example crashes if timer_group_set_alarm_value_in_isr is not called (IDFGH-5229) May 9, 2021
@felmue
Copy link

felmue commented May 10, 2021

Hello @stokmanis

I assume the unaltered example runs ok and w/o crash on your board, yes?

How about disabling auto reload when the timer is initialised?
E.g. change line
example_tg_timer_init(TIMER_GROUP_0, TIMER_0, true, 3);
to
example_tg_timer_init(TIMER_GROUP_0, TIMER_0, false, 3);

Thanks
Felix

@stokmanis
Copy link
Author

The problem is with autoreload disabled
The code timer_group_set_alarm_value_in_isr(info->timer_group, info->timer_idx, timer_counter_value);
is called only when auto reload == false

@felmue
Copy link

felmue commented May 10, 2021

Hello @stokmanis

sorry about that, my bad.

Have you tried to use esp_err_t timer_pause(timer_group_t group_num, timer_idx_t timer_num) when the alarm has fired once?

Thanks
Felix

@stokmanis
Copy link
Author

Yes, timer_pause resolve the issue, and application does not crash. But the functional requirement is to keep timer running.
What is the way to run single timer alert and keep timer running?

@felmue
Copy link

felmue commented May 10, 2021

Hello @stokmanis

there is also a function to disable an alarm. Maybe that is what you are looking for?

esp_err_t timer_set_alarm(timer_group_t group_num, timer_idx_t timer_num, timer_alarm_t alarm_en)

Thanks
Felix

@stokmanis
Copy link
Author

Thanks @felmue , timer_set_alarm did the workaround when called after you received timer event with xQueueReceive(timer_queue...
So the workaround is

  • after 1st alarm is triggered set the fake 2nd alarm in ISR with timer_group_set_alarm_value_in_isr
  • disable alarm outside of ISR with timer_set_alarm

BTW, when working with timer_isr_callback_add it uses timer_isr_default, which automatically reactivates alert after callback function in timer.c line 220
//After the alarm has been triggered, we need enable it again, so it is triggered the next time. timer_hal_set_alarm_enable(&(timer_obj->hal), TIMER_ALARM_EN);

@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: Done Issue is done internally and removed Status: Opened Issue is new labels Jul 9, 2021
espressif-bot pushed a commit that referenced this issue Dec 24, 2021
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes #7001
Closes #8095
espressif-bot pushed a commit that referenced this issue Dec 27, 2021
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes #7001
Closes #8095
espressif-bot pushed a commit that referenced this issue Jan 16, 2022
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes #7001
Closes #8095
espressif-bot pushed a commit that referenced this issue Jan 30, 2022
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes #7001
Closes #8095
dskulina pushed a commit to playable-tech/esp-idf that referenced this issue Feb 4, 2022
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes espressif#7001
Closes espressif#8095
dskulina pushed a commit to playable-tech/esp-idf that referenced this issue Feb 5, 2022
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes espressif#7001
Closes espressif#8095
espressif-bot pushed a commit that referenced this issue Feb 14, 2022
Alarm will be disabled by hardware when alarm event happend.
In the ISR, if auto-reload is enabled, we should re-enable the alarm.
If the alarm target value is changed in user's callback,
the alarm will be reenabled as well.

Closes #7001
Closes #8095
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

3 participants