USB is protected by a mutex. The kernel uses a notification feature which monitors every mutex. The kernel does not understand that this is an ISR. The kernel itself locks up. It uses two mutex locks and the SMP scheduler is capable of splitting them across the cores. Creating a deadlock which the kernel is not capable of detecting, avoiding or handling.
ISRs are like pointers. ISRs should be non-blocking and run below the OS. The OS must respect them. The hardware subsystem can overrule the OS scheduler. Design the ISRs around lockless synchronous designs which behaves asynchronously. The SDK could not do this in this case. The SDK runs a kernel/user thread in the ISR. This challenges the resource management expectation/benefit of FreeRTOS.
As outlined in the issue there are workarounds. Please check if an update has already gone in. Maybe someday they will implement a device driver for us which is actually a valid thread. There was talk of an async task using a very round about path to do that for you. (Your welcome...)
ISRs are like pointers. ISRs should be non-blocking and run below the OS. The OS must respect them. The hardware subsystem can overrule the OS scheduler. Design the ISRs around lockless synchronous designs which behaves asynchronously. The SDK could not do this in this case. The SDK runs a kernel/user thread in the ISR. This challenges the resource management expectation/benefit of FreeRTOS.
As outlined in the issue there are workarounds. Please check if an update has already gone in. Maybe someday they will implement a device driver for us which is actually a valid thread. There was talk of an async task using a very round about path to do that for you. (Your welcome...)
Statistics: Posted by dthacher — Tue Sep 10, 2024 10:43 pm