Open Virus-V opened 6 months ago
@Virus-V nice work finding and debugging this issue! Kudos!!!
@xiaoxiang781216 @raiden00pl any suggestion?
@Virus-V maybe using RAMLOG as SYSLOG instead of SYSLOG over serial could help, them you just run dmesg later to see what happened.
Note: take care with using USB Trace, as Greg explained some years ago: when you add tracing you are changing the timing of USB and it could introduce issues.
This is a known issue we found many time before: https://github.com/apache/nuttx/issues/1138 One possible solution postpone the preemption until leave_critical_section.
It is unsafe to call syslog in a critical section.
Not only usbdev, there are similar codes in other drivers in nuttx (such as drivers/timers/pwm.c).
When I was debugging the STM32F405 USB function, I encountered a crash.
It seemed that the data structure was damaged.
The cause of this problem is that the interrupt was responded to in the critical section.
This problem only occurred after I turned on the USB DEBUG function.
I found that in the
syslog_putc
function, different output functions are called according to the current calling context.However, it does not handle the current situation in the critical section, resulting in task scheduling and interrupts being turned on in the critical section.