STMicroelectronics / STM32CubeF7

STM32Cube MCU Full Package for the STM32F7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
322 stars 191 forks source link

Combination of USB_HOST, FATFS, and FreeRTOS crashes for too small stack size #47

Closed FBergemann closed 2 years ago

FBergemann commented 3 years ago

I followed guidelines from http://evenlund.blogspot.com/2016/10/usb-storage-with-stm32f4-discovery-and_58.html, and increased value for "Device Configuration Tool" / "Project Manager" / "Minimum Stack Size" to 0x800. But the generated code still used 0x80 (128) for separate setting in "USB_HOST" / Parameter Settings / USBH_PROCESS_STACK_SIZE.

As a consequence thread USBH_Process_OS() crashed here:

Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap) HardFault_Handler() at stm32f7xx_it.c:92 0x8000d82 <signal handler called>() at 0xfffffff1 HAL_TIM_IRQHandler() at stm32f7xx_hal_tim.c:3,744 0x8005088 TIM1_UP_TIM10_IRQHandler() at stm32f7xx_it.c:190 0x8000dc6 <signal handler called>() at 0xfffffff1 memcpy() at 0x800efae prvCopyDataToQueue() at queue.c:2,098 0x800c0fe xQueueGenericSendFromISR() at queue.c:1,001 0x800b9a8 osMessageQueuePut() at cmsis_os2.c:1,667 0x800b008 USBH_LL_PortEnabled() at usbh_core.c:1,204 0x80099da HAL_HCD_PortEnabled_Callback() at usbh_conf.c:181 0x800e520 HCD_Port_IRQHandler() at stm32f7xx_hal_hcd.c:1,695 0x80037c6 HAL_HCD_IRQHandler() at stm32f7xx_hal_hcd.c:554 0x8002310 OTG_FS_IRQHandler() at stm32f7xx_it.c:232 0x8000e06 <signal handler called>() at 0xfffffffd prvPortStartFirstTask() at port.c:261 0x800dbf8
xPortStartScheduler() at port.c:367 0x800dcd0

I could fix it by extending the stack size value also for "USB_HOST" / Parameter Settings / USBH_PROCESS_STACK_SIZE.

I am not sure, if increasing the stack size in "Device Configuration Tool" / "Project Manager" / "Minimum Stack Size" is required for this. Or if update of value in "USB_HOST" / Parameter Settings / USBH_PROCESS_STACK_SIZE should be sufficient(?)

But in any case:

  1. A higher value - as recommended in http://evenlund.blogspot.com/2016/10/usb-storage-with-stm32f4-discovery-and_58.html - seems to be required for code generation. The user should not need to fix this afterwards.
  2. The setting should either be at the right place (where? - please see question above). Or - if required to be increased for both - "Device Configuration Tool" / "Project Manager" / "Minimum Stack Size", and USB_HOST" / Parameter Settings / USBH_PROCESS_STACK_SIZE, then the tool should set the value consistently.
RKOUSTM commented 3 years ago

Hi @FBergemann,

Thank you for your reports.

In order to allow a better analysis of this problem, could you please confirm that when you use one of our applications, the issue is systematically reproducible on your side? If you are application is generated, would you please share the project so that we can reproduce the same behavior and give you an answer.

Thank you again for reports.

With regards,

FBergemann commented 3 years ago

Hi, you can easily re-produce by creating a new STM32 project in STM32CubeIDE - e.g. for board NUCLEO-F767ZI. (For this, i did not initialize all peripherals, and i cleared all PINs in the Device Configuration Tool (CubeMX) view - but this shouldn't make a difference for the problem here.)

Then

save *.ioc file

Then check "Middleware / USB_HOST", Parameter Settings / CMSIS_RTOS / USBH_PROCESS_STACK_SIZE (128 Words)

The value here is too small.

BTW I didn't find any reference project for "USB_HOST / Mass Storage Host Class" that is using the Device Configuration Tool (CubeMX). All examples/references i was given, didn't use *.ioc file. It would be good to have examples, that are based on the Device Configuration Tool (CubeMX). Then those problems would have shown up already, before. Note, that i also filed another issue void MX_DriverVbusFS(uint8_t state) - wrong state evaluation? for this. And currently i am struggling with a 3rd problems, which is about wrong intialization of PA10 (USB_OTS_FS_ID) (i will create another separate issue for that).

RKOUSTM commented 2 years ago

Hi @FBergemann,

Thank you for your reports. The point you reported is related to the CubeMX generation and not directly related to the firmware published in this repository. Unfortunately, we don't treat aspect related to CubeMX tool in our GitHub repositories. Moreover, we do not deliver IOC files in the STM32CubeF7 package.

To properly initialize the parameters of a USB_HOST / Mass Storage Host Class application, you can use the following CubeMX steps:

  1. Set the System Clock Configuration, so that you can provide an accurate clock for the USB timing.
  2. Select the USB_OTG_FS in Host Only mode. Also make sure you enable VBUS, as USB devices usually do not have a power supply, and therefore VBUS will provide the necessary power to these devices.
  3. Select the USB_HOST in the Middleware section and choice the Mass Storage Host Class. Also, you want to set the Drive_VBUS_FS to GPIO_Output PG6 under USB_Host Configuration subsection: USB2

    4- The USBH_PROCESS_STACK_SIZE parameter is used by the main USB Host thread. This parameter can be varied from 128 words to 3.84 KWords, so you can adapt it to your use case. For example, you can set it as follows:

    USB3

In addition, you can adapt this MSC_RTOS application on STM32F769I_EVAL to develop an USB host application based on the Mass Storage Class (MSC) on the STM32F7x6 devices in RTOS mode configuration for any other development board.

For any other issue (e.g. related to documentation, to hardware, to ecosystem, to user application, etc.), you shall address your questions to the ST Community. There you shall find people who will address your request and whom you will hopefully find a solution with.

Now, as this issue is not directly related to some software component published within this repository (CMSIS, HAL, BSP, etc.) but rather to our ecosystem (namely the Cube MX tool), please allow me to close it.

Thank you for your contribution. I hope this answer addresses your need. We are looking forward to reading from you again.

With regards,