Open andylinpersonal opened 6 months ago
Hi @andylinpersonal! I have tried to reproduce it but still no luck. I am getting 1ms for both w and w/o FREERTOS_WATCHPOINT_END_OF_STACK + w and w/o the debug probe attached. I used the C6 chip with your example. Does it happen on the master as well?
Your result:
0x7D000 = 512000 ticks,
512000 / 32 (max_intr_counter = 32) / 16 (systimer division) = 1000us. Which is equal to the used CONFIG_FREERTOS_HZ=1000.
(It seems this is without FREERTOS_WATCHPOINT_END_OF_STACK) 0x00000000095B2A0B = 156969483 ticks 156969483 / 16384 (max_intr_counter = 16384) / 16 (systimer division) = 598us. Which is even less than 1ms. Could you explain this case? Is it for 16384 or not?
@andylinpersonal It seems I have reproduced this case. I slightly changed your example. This example works well when CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK=n or debug is not attached. The issue occurs when CONFIG_FREERTOS_WATCHPOINT_END_OF_STACK=y and the debug is attached. I am getting the 32 Systick interrupts not within 32ms as expected (1 tick is 1ms, CONFIG_FREERTOS_HZ=1000) but within 10sec. Which is 312 times longer. I will check why it works like that.
BTW, attaching the OpenOCD to running ESP32-C3s and ESP32-C6s will trigger infinite unhandled debug exceptions occasionally, which cannot be eliminated without a full power cycle. It's strange. 😅
Answers checklist.
IDF version.
release/v5.1 and release/v5.2
Espressif SoC revision.
ESP32-C3 (QFN32) (revision v0.3) and ESP32-C6 revision 0.0
Operating System used.
Linux
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
C3: Custom board, C6: ESP32-C6-DevkitC-N8
Power Supply used.
USB
What is the expected behavior?
System should not be clogged even with the debug probe attached and enabled on it.
What is the actual behavior?
When the system is busy (simulated by two busy printing tasks) and compiled with
FREERTOS_WATCHPOINT_END_OF_STACK=y
, system will become very slow and the serving of ISRs are severely deferred (use systick as demo). BTW, this issue also affect the interrupt-intensive tasks. I have been successfully reproduced on the I2C and I2S over GDMA.Steps to reproduce.
FREERTOS_WATCHPOINT_END_OF_STACK=y
in thesdkconfig.defaults
.openocd -f 'board/$CHIP-builtin.cfg'
and open the console of openocd bytelnet localhost 4444
.idf.py monitor -p $PORT --no-reset
.reset
.FREERTOS_WATCHPOINT_END_OF_STACK
.Debug Logs.
C6 with debugger attached
C6 without debugger
More Information.
main.c
Snippets to be added to the systick handler or global interrupt handler: (Choose one of the two and see the console output)
components/freertos/port_systick.c
components/riscv/interrupt.c
sdkconfig.defaults