2014-04-08 02:51 AM
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
2014-04-08 06:04 AM
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,2014-04-08 06:22 AM
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
2014-04-08 08:30 AM
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,
2014-04-08 08:56 AM
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 Bert2014-04-08 09:47 AM
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,2014-04-08 10:36 AM
It's more or less the code straight from STMCube, files attached. Apologies if I missed something blindingly obvious, as I'm starting to suspect might be the case.
Bert ________________ Attachments : Acc4.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0cd&d=%2Fa%2F0X0000000bcB%2FvYv3cW984VX46aX5hfjtzb.zbzZWlL9BLuW1spCwMQQ&asPdf=falsemain.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0X4&d=%2Fa%2F0X0000000bcC%2FUTdGaxqliZsC56U320nC.4ePqXZUT8Hxuc83PEdfwt0&asPdf=falseusbh_conf.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0fa&d=%2Fa%2F0X0000000bcD%2FSHTuRqyQvpb3tAUohjwMiDaQCN7I143o575exLj3XFE&asPdf=false2014-04-09 01:29 AM
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,
2014-04-09 05:50 AM
Just to confirm it works perfectly with this fix, thanks for your help.
Bert