Mcu stop when using f_write in usb host msc on stm32 f4.

[SWoon]

Hello.

I want to operate the USB HOST MSC as FATFS with STM32 F4.

My code periodically records data to usb.

It works normally for quite a long time.

But if it works for a day, the mcu keeps stopping.

The problem seems to be periodic f_write. 

Because it does not stop if the MCU does not use FATFS.

I've searched for solutions. In SD-CARD, f_write does not stop using __disable_irq() and __enable_irq().

So I applied what I found. However, the problem has not been resolved. There's a bigger problem. It does not deviate from the function of USB.

(The functions that are reflected are: USBH_MSC_SCSI_Write(), USBH_MSC_BOT_Process, USBH_MSC_RdWrProcess(), etc.)

Is the use of __disable_irq(), __enable_irq() different in usb?

If it's not available, please ask me to do something else that I can do.

[AvaTar]

Not clear what you are talking about.

Is the Flash file system located on a SD card, or in internal Flash of the MCU ?

Anyway, Flash programming takes time.

If a sector boundary is reached, and a sector needs to be erased for programming, the SD card will return busy, and execution from internal Flash will stall.

An erase can take up to hundreds of milliseconds, check the datasheet.

[Tesla DeLorean]

Sorry not familiar with your code, what role is enable/disable IRQ playing here? A crude Critical Section? Instead of a mutex/semaphore for ownership of FATFS or MSC-USB resources? ​

[SWoon]

The reason I enable/disable IRQ is the Critical Section. 

The solution I found was to have the application of FATFS handled a similar problem by conducting a Critical Section. The person who created this method uses sd-card.

However, there was a problem with usb host msc.

[Tesla DeLorean]

If you hold things too long or don't nest properly things are going to break. You'll need to find a better way to arbitrate and sequence ownership of resources. Work needs to be done in separate threads and not stall or block in interrupt and callback routines.​