I have a project using the ESP32's PCNT peripheral to count pulses from a sensor. I don't have the sensor yet, but I'm trying to simulate sensor values with a function generator set to 50% duty cycle and 3.3V square waves. When I switch from the 2 KHz scale to the 20 KHz scale, or 20 KHz scale to the 200 KHz scale, the ESP32 crashes and goes into what looks like an infinite reset loop. I get the message:
"abort() was called at PC 0x4008216f on core 0"
I've modified the pcnt example and removed most of the interrupts, except for the H LIM EVT. I've disabled the LED PWM config since I'm using the function generator. The code seems to work until I move up to a faster scale. I need to count quite large numbers of pulses so I have a global variable that contains the running total. I poll the PCNT value and add it into this variable and then clear PCNT and resume. If the H LIM EVT interrupt happens, I am using that as an overflow protection which also adds the PCNT into a global variable and then clears the counter.
If I turn up the frequency using the knob on the function generator it seems to work just fine. The problem only occurs when I jump to a higher scale. I was unable to find a high voltage spike on the frequency jump on my scope, but my scope can be finicky with triggering on something like that.
I'm pretty new to embedded programming so I'm sure I'm doing something really stupid. Any thoughts on what can cause this?
Thanks
PCNT hardware counter crashing
Re: PCNT hardware counter crashing
If you are using 'make monitor' to view serial output, you should get a backtrace showing from which function abort was called. If you post complete output from make monitor, someone here may help you figure out what goes wrong.
Re: PCNT hardware counter crashing
Here is the output of make monitor after the crash:
Thanks!0x4008216f: lock_acquire_generic at C:/esp-idf/components/newlib/locks.c:141
Backtrace: 0x40086184:0x3ffc01c0 0x40086283:0x3ffc01e0 0x4008216f:0x3ffc0200 0x4
008228d:0x3ffc0230 0x400d4ede:0x3ffc0250 0x400d8119:0x3ffc0560 0x40081e35:0x3ffc
0590 0x40081eda:0x3ffc05e0 0x400819ae:0x3ffc0610
0x40086184: invoke_abort at C:/esp-idf/components/esp32/panic.c:546
0x40086283: abort at C:/esp-idf/components/esp32/panic.c:546
0x4008216f: lock_acquire_generic at C:/esp-idf/components/newlib/locks.c:141
0x4008228d: _lock_acquire_recursive at C:/esp-idf/components/newlib/locks.c:169
0x400d4ede: _vfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2
.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf
.c:860 (discriminator 2)
0x400d8119: vprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0
/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vprintf.c:39
0x40081e35: esp_log_write at C:/esp-idf/components/log/log.c:190
0x40081eda: pcnt_example_intr_handler at C:/Users/stej01/Neon-Workspace/pcnt/mai
n/pcnt_example_main.c:106 (discriminator 1)
0x400819ae: _xt_lowint1 at xtensa_vectors.o:?
Backtrace: 0x40085695:0x3ffbfe00 0x40084554:0x3ffbfe20 0x400866b1:0x3ffbfe50 0x4
0086a26:0x3ffc0020 0x4008639d:0x3ffc0060 0x400864f8:0x3ffc00e0 0x40081752:0x3ffc
0100 0x40086181:0x3ffc01c0 0x40086181:0x3ffc01e0 0x4008216f:0x3ffc0200 0x4008228
d:0x3ffc0230 0x400d4ede:0x3ffc0250 0x400d8119:0x3ffc0560 0x40081e35:0x3ffc0590 0
x40081eda:0x3ffc05e0 0x400819ae:0x3ffc0610
0x40085695: prvTaskGetSnapshot at C:/esp-idf/components/freertos/tasks.c:4994
0x40084554: uxTaskGetSnapshotAll at C:/esp-idf/components/freertos/tasks.c:5054
(discriminator 2)
0x400866b1: esp_core_dump_write at C:/esp-idf/components/esp32/core_dump.c:112
0x40086a26: esp_core_dump_to_uart at C:/esp-idf/components/esp32/core_dump.c:534
0x4008639d: commonErrorHandler at C:/esp-idf/components/esp32/panic.c:546
0x400864f8: xt_unhandled_exception at C:/esp-idf/components/esp32/panic.c:546
0x40081752: _xt_user_exc at xtensa_vectors.o:?
0x40086181: invoke_abort at C:/esp-idf/components/esp32/panic.c:546
0x40086181: invoke_abort at C:/esp-idf/components/esp32/panic.c:546
0x4008216f: lock_acquire_generic at C:/esp-idf/components/newlib/locks.c:141
0x4008228d: _lock_acquire_recursive at C:/esp-idf/components/newlib/locks.c:169
0x400d4ede: _vfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2
.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf
.c:860 (discriminator 2)
Traceback (most recent call last):
File "C:/esp-idf/tools/idf_monitor.py", line 552, in <module>
main()
File "C:/esp-idf/tools/idf_monitor.py", line 486, in main
monitor.main_loop()
File "C:/esp-idf/tools/idf_monitor.py", line 253, in main_loop
self.handle_serial_input(data)
File "C:/esp-idf/tools/idf_monitor.py", line 286, in handle_serial_input
self.handle_serial_input_line(self._read_line.strip())
File "C:/esp-idf/tools/idf_monitor.py", line 294, in handle_serial_input_line
self.lookup_pc_address(m.group())
File "C:/esp-idf/tools/idf_monitor.py", line 383, in lookup_pc_address
cwd=".")
File "C:/msys32/mingw32/lib/python2.7/subprocess.py", line 214, in check_outpu
t
output, unused_err = process.communicate()
File "C:/msys32/mingw32/lib/python2.7/subprocess.py", line 402, in communicate
stdout = _eintr_retry_call(self.stdout.read)
File "C:/msys32/mingw32/lib/python2.7/subprocess.py", line 122, in _eintr_retr
y_call
return func(*args)
Re: PCNT hardware counter crashing
You are trying to use ESP_LOG (effectively printf) from an interrupt. That will not work. Interrupts should do bare minimum of work, and certainly not formatted IO.
Re: PCNT hardware counter crashing
Ok, I feel stupid now. It occurred to me that the printf and log stuff might be a problem in the ISR, so I commented them out. Turns out I missed one.
I commented this last one out and now it works without crashing. Thanks!
I commented this last one out and now it works without crashing. Thanks!
Who is online
Users browsing this forum: Google [Bot] and 121 guests