Skip to main content
brett
brett
Associate II
April 8, 2014
Question

STMCube USB Host code not working

  • April 8, 2014
  • 8 replies
  • 2144 views
Posted on April 08, 2014 at 11:51

Hi,

I can't get the USB Host code generated by STMCube to work. When I connect a device, none of the interrupts get triggered - the software doesn't seem to recognize it at all. The peripheral clock is enabled and the interrupts are getting set, I see this function get called in usbh_conf.c in the debugger: 

void
HAL_HCD_MspInit(HCD_HandleTypeDef* hhcd){
GPIO_InitTypeDef GPIO_InitStruct;
if
(hhcd->Instance==USB_OTG_FS)
{
/* Peripheral clock enable */
__USB_OTG_FS_CLK_ENABLE();
/**USB_OTG_FS GPIO Configuration 

PA11 ------> USB_OTG_FS_DM
PA12 ------> USB_OTG_FS_DP 
*/

GPIO_InitStruct.Pin = GPIO_PIN_11|GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
GPIO_InitStruct.Alternate = GPIO_AF10_OTG_FS;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
/* Peripheral interrupt init*/
/* Sets the priority grouping field */
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_0);
HAL_NVIC_SetPriority(OTG_FS_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(OTG_FS_IRQn);
}
}

But I never see the interrupt routines run or the user callback functions get called. My device is definitely receiving power from the bus. Is there anything obvious I'm missing? Thanks Bert #stm32f4 #usb #stm32cubemx-bug-hsi-usb-48mhz
This topic has been closed for replies.

8 replies

Montassar BEN ROMDHANE_O
Montassar BEN ROMDHANE_O
Visitor II
April 8, 2014
Posted on April 08, 2014 at 15:04

Hi Bert,

Can you specify the MCU/Board your are working with? And also the USBH Mode/Class?

In fact,  within the generated usbh_conf.c file you have to:

- Initialize the Power Switch GPIO (depends on your platform)

- Add your own code to drive high/low the charge pump under USBH_LL_DriverVBUS() function.

Regards,

brett
brettAuthor
Associate II
April 8, 2014
Posted on April 08, 2014 at 15:22

Hi,

So I'm actually prototyping with a Discovery board at the minute although hopefully this will be our own PCB in the near future. So in the USBH_LL_DriverVBUS function in USBH_conf.c I have: 

HAL_GPIO_WritePin(GPIOC, GPIO_PIN_0, GPIO_PIN_RESET);

And obviously I've enabled the peripheral clock for the GPIOC bank. I can see 5V on the bus ok. This is USB FS, class is MSC. The actual MCU is STM32F407VGT6. Thanks Bert
Montassar BEN ROMDHANE_O
Montassar BEN ROMDHANE_O
Visitor II
April 8, 2014
Posted on April 08, 2014 at 17:30

Hi,

Driving the charge pump high/low is done through the Port H, Pin 5. YouUSBH_LL_DriverVBUS() should be as follows: 

USBH_StatusTypeDef USBH_LL_DriverVBUS (USBH_HandleTypeDef *phost, uint8_t state)
{
if(phost->pData == USB_OTG_FS)
{ 
if(state == 0)
{
/* Drive high Charge pump */
/* USER CODE BEGIN 0 */ 
/* ToDo: Add IOE driver control */
 HAL_GPIO_WritePin(GPIOH, GPIO_PIN_5, GPIO_PIN_SET);

/* USER CODE END 0 */ 
}
else
{
/* Drive low Charge pump */
/* USER CODE BEGIN 1 */
/* ToDo: Add IOE driver control */
 HAL_GPIO_WritePin(GPIOH, GPIO_PIN_5, GPIO_PIN_RESET);

/* USER CODE END 1 */
}
}
else
{
/* if HS is use in Low Speed i.e. embedded phy (internal phy) */
/* Add you code here to drive charge pump */
/* USER CODE BEGIN 2 */
/* USER CODE END 2 */
}
HAL_Delay(200);
return USBH_OK; 
}

Regards,
brett
brettAuthor
Associate II
April 8, 2014
Posted on April 08, 2014 at 17:56

Hi,

Thanks for your reply. The STM32F407VGT6 has no bank H pin 5. According to the schematic for the discovery board, the charge pump enable is connected to bank C pin 0. The bus is definitely being powered and the device powers up, so I don't think this is a problem with my USBH_LL_DriverVBUS function or a power related issue in general.

Thanks

Bert

Montassar BEN ROMDHANE_O
Montassar BEN ROMDHANE_O
Visitor II
April 8, 2014
Posted on April 08, 2014 at 18:47

Hi,

Can you attach your main.c / usbh_conf.c and your project.ico files ?

I've done the requested manipulation and it's working well.

Regards,

Montassar BEN ROMDHANE_O
Montassar BEN ROMDHANE_O
Visitor II
April 9, 2014
Posted on April 09, 2014 at 10:29

Hi,

Analyzing the generated code, the issue lies in the System clock configuration generated function. It should be as follows: 

/** System Clock Configuration
*/
static void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.HSICalibrationValue = 6;
 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
 RCC_OscInitStruct.PLL.PLLM = 16;
 RCC_OscInitStruct.PLL.PLLN = 192;
 RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
 RCC_OscInitStruct.PLL.PLLQ = 4;

HAL_RCC_OscConfig(&RCC_OscInitStruct);
}

I confirm that's anSTM32CubeMX bug, when generating clock configuration using HSI as PLL source. You can add the missed configuration lines, or you can work directly with HSE. Regards,
brett
brettAuthor
Associate II
April 9, 2014
Posted on April 09, 2014 at 14:50

Just to confirm it works perfectly with this fix, thanks for your help.

Bert
Terms & ConditionsAccessibility statement