Hard Fault in USBH_MSC_RdWrProcess() and USBH_MSC_GetLUNInfo()

[unsigned_char_array]

I have a STM32H7 and I use USB MSC. I do not use an RTOS.
If I plug in my USB thumb drive I append a counter to a file and close it.
This works.
If I remove the thumb drive very quickly at precisely the wrong moment I get a hardfault.
if Appli_state == APPLICATION_READY I set a flag and call f_open in the main loop. But then the USB drive is already gone, but there is no NULL pointer check.

We call the USBH_Process() and USBH_MSC_AppProcess() in a timer interrupt and have modified it to have non-blocking delays. I wonder if this could be the cause or if there is an actual bug in the driver that misses to check the USB drive is not available.

The following modification made to USBH_MSC_RdWrProcess() fixes the problem of hardfaults.

static USBH_StatusTypeDef USBH_MSC_RdWrProcess(USBH_HandleTypeDef *phost, uint8_t lun)
{
  USBH_StatusTypeDef error = USBH_BUSY;
  USBH_StatusTypeDef scsi_status = USBH_BUSY;

  if (phost->pActiveClass == NULL)
  {
      error = USBH_FAIL;
      return error;
  }

  MSC_HandleTypeDef *MSC_Handle = (MSC_HandleTypeDef *) phost->pActiveClass->pData;

Edit: I found an old thread that mentions the same problem:

https://community.st.com/t5/stm32-mcus-embedded-software/usb-host-library-is-not-thread-safe/m-p/307489

Another modification I made is to call an idle handler in busy waiting loops. This is not the cause of the issue, but it does address the issue mentioned by @NAgha.1 in that topic:

  while (USBH_MSC_RdWrProcess(phost, lun) == USBH_BUSY)
  {
    if (((phost->Timer - timeout) > (10000U * length)) || (phost->device.PortEnabled == 0U))
    {
      return USBH_FAIL;
    }
    // start of modification
    else
    {
    	// prevent blocking other processes from main context
    	usbIdleLoop();
    }
    // end of modification
  }

main:

void usbIdleLoop()
{
    //does non-usb things
}

int main(){
...
while(1)
{
usbIdleLoop();
usbApplication();//does fat-fs things with usb and calls usbIdleLoop in loops that were previously busy waiting to prevent blocking
}
}

[FBL]

Hi @unsigned_char_array 

Thanks for reporting the issue!

Would you share an example project to reproduce on my end?

[unsigned_char_array]

That's going to be difficult, because I use a custom board. I do have a development board (STM32H735G-DK), but this one doesn't have a USB-A receptacle. I can strip the code I have right now, but pins might be different. Is that ok?
Also the problem is hard to reproduce since it requires disconnecting the thumb drive at exactly the right moment.
Maybe I can modify the code so it does more reading and writing to increase the odds of a crash.