USBX blocking ISR

[MHerr.8]

Hi,

during porting the USBX as host stack to an stm32h7 I was getting an error indication,

that a semaphore was used during interrupt context (OTG_HS_IRQHandler).

For my opinion, it is wrong to call the generated code out of the ISR without decoupling the context.

How did you solve the problem? Is there a posibility in cubemx the generate code with decoupling the context?

.

[FBL]

Hi @MHerr.8 

AFAIK, semaphores should not be used directly in ISR. Could you explain what do you mean MX generates code in decoupling context?

[skydiver]

Hey, so I just ran into the same thing while trying to figure out how to make a dual-role device on my own (since there is basically no support for this in CubeMX as far as I can tell).  I think I have figured out a way to make HAL_HCD and HAL_PCD coexist, but in the process of debugging this I threw a printf() in the ux_host_error_callback() function and discovered that I am getting several TX_WAIT_ERRORs when I run the MSC demo code.

The Problem:

The TX_WAIT_ERROR is generated because _ux_utility_memory_free() is called in the _ux_hcd_stm32_request_trans_finish() function, which is called by HAL_HCD_HC_NotifyURBChange_Callback(), which is called by HCD_HC_OUT_IRQHandler(), which is called by HAL_HCD_IRQHandler(), which I call in OTG_HS_IRQHandler() (which is the actual ISR).  In my case the version of HAL_HCD_HC_NotifyURBChange_Callback() that is called is the one in stm32u5xx_hal_hcd.c.  The function comment header does not list several of the calls that are made (including the offending one).  This is how the MSC demo application is structured, so I would expect this to be the intended use case for the library.

The failed mutex wait does not alter the flow of the function, because _ux_system_mutex_on() just returns void.  The memory free in the ISR context does appear to be successful, though, because in the USB thread the code in _ux_hcd_stm32_request_control_transfer() *also* attempts to free the same memory later (after _ux_host_semaphore_get() returns once the transfer is completed).  The error code is UX_MEMORY_CORRUPTED (25), but in the debugger it looks like this is being set because the block is no longer marked as used (memory_block -> ux_memory_block_status does not have the UX_MEMORY_USED flag set).

I believe this is a bug, since taking a mutex in an ISR is not a valid operation (since the ISR cannot own the mutex).  The utility mutex code is fairly explicit in returning an error before actually attempting to take the lock.  Logically it could still work, but I worry for the rare chance that another part of the stack is freeing memory when this ISR is called, because the mutex is actually protecting nothing.  In any case, doing memory management in the ISR does not make any sense.

As a side-note, I discovered that my project is using an older version of the USB support files.  The version for _ux_utility_memory_free() in my code is 6.1.10, while the USBPD_SRC_UX_Host_MSC demo is on 6.3.0 (even though it was generated with the same IDE within weeks of the other project).  It is a slightly different U5 target (one without the HS peripheral), but it also has this bug.  The main reason I bring this up is that the memory management appears to be very different, so the second error code (25) may not happen, but the first error accessing the mutex in an ISR definitely will.

Decoupling the Context:

I believe they are asking if CubeMX has an option to generate code which decouples the handling of interrupts as it should always do (no waiting on mutexes/semaphores/etc in an ISR, no long-running operations).  I don't believe this is a code generation problem, though, because it is code that is in the USER blocks of your demo applications which calls these HAL ISR handler functions in the actual interrupt handler.  These projects document this as the correct way to use the function, and as far as I can tell there is no indication otherwise.

I am planning to decouple this by having OTG_HS_IRQHandler() just set a semaphore flag, and have a separate high-priority ISR processing task which calls HAL_HCD_IRQHandler().  I believe there is another forum post about this same issue where someone did this, but in their case this caused HS mode to fail.

I'm hoping this will be a workable solution for my project, but even if so this has not been a very pleasant experience.