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.

Sign up for GitHub

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

Jump to bottom

[TW#28622] Starting of wifi softAP and modbus slave, the system was crashed. Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) #3009

Closed
patrykkrz opened this issue Jan 30, 2019 · 1 comment
Closed

[TW#28622] Starting of wifi softAP and modbus slave, the system was crashed. Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) #3009

patrykkrz opened this issue Jan 30, 2019 · 1 comment

Comments

@patrykkrz
Copy link
Contributor

patrykkrz commented Jan 30, 2019 •
edited
Loading

Environment

  • Development Kit: [none]
  • Module or chip used: [ESP32-WROOM-32]
  • IDF version: v3.3-beta1-268-g5c88c5996
  • Build System: [Make]
  • Compiler version: (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 5.2.0
  • Operating System: [Windows]
  • Power Supply: [USB]

Problem Description

When you start WIFI SoftAP and then modbus slave, the system will be damaged.

Steps to repropduce

  1. Init esp event loop. In event function handler, print log when event id is AP_START.
  2. Configure and start WifiSoft AP.
  3. Init and start modbus slave (modbus slave is almost identical to an example: examples/protocols/modbus_slave).

Remarks

In this case, the time interval is important. When you add or delete some logs in my code, the problem may not occur. When I add a delay before running the modbus slave, the problem also does not occur.
Adding a delay solves the problem, but I think it is deceptive.
I have not sent or received data via modbus, but I am afraid there may be similar problems.

When I was looking for an answer to why this is happening, I found this information and issues:

In the modbus slave component (mbrtu.c), critical sections are used. For example in function eMBRTUInit.
The order of calling the function:

  • eMBRTUInit
  • ENTER_CRITICAL_SECTION
  • xMBPortSerialInit
  • uart_driver_install (in this function, freeRTOS API functions was called)

Code to reproduce this issue

https://gist.github.com/patrykkrz/10709e49751d4915467dcfeb6e089cf8

Debug Logs

I (1367) MODBUS_SLAVE_APP: mb_slave_task started.
I (1367) MAIN: SYSTEM_EVENT_AP_START
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x4008f32f  PS      : 0x00060034  A0      : 0x8009041d  A1      : 0x3ffbf170
0x4008f32f: vPortCPUAcquireMutexIntsDisabledInternal at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:5093
 (inlined by) vPortCPUAcquireMutexIntsDisabled at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/portmux_impl.h:98
 (inlined by) vTaskEnterCritical at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:4231

A2      : 0x3ffb0428  A3      : 0x00000000  A4      : 0x3ffba3a4  A5      : 0x00000001
A6      : 0x00060e23  A7      : 0x3ffbb494  A8      : 0x0000abab  A9      : 0x0000cdcd
A10     : 0xb33fffff  A11     : 0x0000abab  A12     : 0x00000030  A13     : 0x00000001
A14     : 0x00060023  A15     : 0x3ffb4268  SAR     : 0x00000004  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffe

Backtrace: 0x4008f32f:0x3ffbf170 0x4009041a:0x3ffbf190 0x40090832:0x3ffbf1b0 0x40090b78:0x3ffbf1d0 0x40090ca9:0x3ffbf210 0x40082c52:0x3ffbf230 0x40082d29:0x3ffbf260 0x400e614e:0x3ffbf280 0x400e50df:0x3ffbf2a0 0x4000bd83:0x3ffbf2c0 0x4000117d:0x3ffbf2e0 0x400592fe:0x3ffbf
300 0x4005937a:0x3ffbf320 0x40058bbf:0x3ffbf340 0x400d741d:0x3ffbf370 0x400dcc06:0x3ffbf3a0 0x400dcd49:0x3ffbf6b0 0x40082af1:0x3ffbf6e0 0x400d2cf1:0x3ffbf730 0x400ea665:0x3ffbf750 0x400ea6a1:0x3ffbf770 0x400905cd:0x3ffbf7c0
0x4008f32f: vPortCPUAcquireMutexIntsDisabledInternal at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:5093
 (inlined by) vPortCPUAcquireMutexIntsDisabled at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/portmux_impl.h:98
 (inlined by) vTaskEnterCritical at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:4231

0x4009041a: xTaskPriorityDisinherit at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:5093

0x40090832: prvCopyDataToQueue at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/queue.c:2037

0x40090b78: xQueueGenericSend at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/queue.c:2037

0x40090ca9: xQueueGiveMutexRecursive at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/queue.c:2037

0x40082c52: lock_release_generic at D:/proj/SEV-ModbusCrash/esp-idf/components/newlib/locks.c:205

0x40082d29: _lock_release_recursive at D:/proj/SEV-ModbusCrash/esp-idf/components/newlib/locks.c:217

0x400e614e: uart_write at D:/proj/SEV-ModbusCrash/esp-idf/components/vfs/vfs_uart.c:141

0x400e50df: esp_vfs_write at D:/proj/SEV-ModbusCrash/esp-idf/components/vfs/vfs.c:962

0x400d741d: __sprint_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:437

0x400dcc06: _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:1782 (discriminator 1)

0x400dcd49: 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

0x40082af1: esp_log_write at D:/proj/SEV-ModbusCrash/esp-idf/components/log/log.c:121

0x400d2cf1: event_handler at D:/proj/SEV-ModbusCrash/main/main.c:44 (discriminator 9)

0x400ea665: esp_event_post_to_user at D:/proj/SEV-ModbusCrash/esp-idf/components/esp32/event_loop.c:109

0x400ea6a1: esp_event_loop_task at D:/proj/SEV-ModbusCrash/esp-idf/components/esp32/event_loop.c:109

0x400905cd: vPortTaskWrapper at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/port.c:403


Core 1 register dump:
PC      : 0x40091b76  PS      : 0x00060c34  A0      : 0x8008ff1a  A1      : 0x3ffc7360
0x40091b76: vListInsert at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/list.c:188

A2      : 0x3ffc0134  A3      : 0x3ffc7a08  A4      : 0x3ffb041c  A5      : 0x00000001
A6      : 0x00060c23  A7      : 0x00000005  A8      : 0x3ffc7a08  A9      : 0x3ffc7a08
A10     : 0x00000014  A11     : 0x00000014  A12     : 0x3ffc77a0  A13     : 0x00000001
A14     : 0x00060c23  A15     : 0x00060023  SAR     : 0x00000004  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffffff

Backtrace: 0x40091b76:0x3ffc7360 0x4008ff17:0x3ffc7380 0x40090f64:0x3ffc73a0 0x40090fcd:0x3ffc73e0 0x40082bf9:0x3ffc7400 0x40082ce9:0x3ffc7430 0x400d9aee:0x3ffc7450 0x400dcd49:0x3ffc7760 0x40082af1:0x3ffc7790 0x400ea292:0x3ffc77e0 0x40120d0b:0x3ffc7830 0x4012135d:0x3ffc7
880 0x401208f3:0x3ffc78a0 0x4012035d:0x3ffc78c0 0x400d3028:0x3ffc78f0 0x400905cd:0x3ffc7960
0x40091b76: vListInsert at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/list.c:188

0x4008ff17: vTaskPlaceOnEventList at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/tasks.c:5093

0x40090f64: xQueueGenericReceive at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/queue.c:2037

0x40090fcd: xQueueTakeMutexRecursive at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/queue.c:2037

0x40082bf9: lock_acquire_generic at D:/proj/SEV-ModbusCrash/esp-idf/components/newlib/locks.c:157

0x40082ce9: _lock_acquire_recursive at D:/proj/SEV-ModbusCrash/esp-idf/components/newlib/locks.c:171

0x400d9aee: _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)

0x400dcd49: 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

0x40082af1: esp_log_write at D:/proj/SEV-ModbusCrash/esp-idf/components/log/log.c:121

0x400ea292: uart_driver_install at D:/proj/SEV-ModbusCrash/esp-idf/components/driver/uart.c:1346

0x40120d0b: xMBPortSerialInit at D:/proj/SEV-ModbusCrash/esp-idf/components/freemodbus/port/portserial.c:265 (discriminator 1)

0x4012135d: eMBRTUInit at D:/proj/SEV-ModbusCrash/esp-idf/components/freemodbus/modbus/rtu/mbrtu.c:90

0x401208f3: eMBInit at D:/proj/SEV-ModbusCrash/esp-idf/components/freemodbus/modbus/mb.c:329

0x4012035d: mbcontroller_start at D:/proj/SEV-ModbusCrash/esp-idf/components/freemodbus/modbus_controller/mbcontroller.c:276

0x400d3028: mb_slave_task at D:/proj/SEV-ModbusCrash/main/modbus/mb_slave.c:118

0x400905cd: vPortTaskWrapper at D:/proj/SEV-ModbusCrash/esp-idf/components/freertos/port.c:403

Attachments

core.zip (elf file and coredump)
main.zip (all sources)
sdkconfig.txt
@Alvin1Zhang Alvin1Zhang changed the title Starting of wifi softAP and modbus slave, the system was crashed. Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) [TW#28622] Starting of wifi softAP and modbus slave, the system was crashed. Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) Jan 31, 2019
@KonstantinKondrashov
Copy link
Collaborator

Hi @patrykkrz. Thanks for the report.

The uart_driver_install function has ESP_LOGI https://github.com/espressif/esp-idf/blob/master/components/driver/uart.c#L1346. We should not call it into ENTER_CRITICAL_SECTION. We will fix it. You can comment on this line or change it onto ESP_EARLY_LOGI.

@igrr igrr closed this as completed in 1ef7d09 Mar 12, 2019
igrr pushed a commit that referenced this issue Mar 12, 2019
@alisitsyn
freemodbus: change critical sections to semaphore mutex
aaa1cb6 
revert changes made in mbrtu.c, mbascii.c
change critical section type to semaphore mutex instead of spin lock

Closes: #3009
igrr pushed a commit that referenced this issue Apr 16, 2019
@alisitsyn
freemodbus: change critical sections to semaphore mutex
7342811 
revert changes made in mbrtu.c, mbascii.c
change critical section type to semaphore mutex instead of spin lock

Closes: #3009
catalinio pushed a commit to catalinio/pycom-esp-idf that referenced this issue Jun 28, 2019
@alisitsyn
freemodbus: change critical sections to semaphore mutex
3e96f86 
revert changes made in mbrtu.c, mbascii.c
change critical section type to semaphore mutex instead of spin lock

Closes: espressif/esp-idf#3009
@alafi alafi mentioned this issue Nov 25, 2019
Closed
2 tasks
0xFEEDC0DE64 pushed a commit to 0xFEEDC0DE64/esp-idf that referenced this issue May 5, 2021
@romansavrulin @me-no-dev
Flush UART RX queue too (espressif#3009)
03066e4
foxval pushed a commit to foxval/esp-idf that referenced this issue Jun 8, 2021
@alisitsyn
freemodbus: change critical sections to semaphore mutex
fb3b5f0 
revert changes made in mbrtu.c, mbascii.c
change critical section type to semaphore mutex instead of spin lock

Closes: espressif#3009
espressif-bot pushed a commit to espressif/esp-modbus that referenced this issue Apr 5, 2022
@KonstantinKondrashov @alisitsyn
freemodbus: Fix remove critical_sections
a3fc6eb 
Closes: espressif/esp-idf#3009


* Original commit: espressif/esp-idf@1ef7d09
espressif-bot pushed a commit to espressif/esp-modbus that referenced this issue Apr 5, 2022
@alisitsyn
freemodbus: change critical sections to semaphore mutex
ce241e3 
revert changes made in mbrtu.c, mbascii.c
change critical section type to semaphore mutex instead of spin lock

Closes: espressif/esp-idf#3009


* Original commit: espressif/esp-idf@aaa1cb6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@patrykkrz @KonstantinKondrashov