2015-01-26 05:48 AM
Hi,
It's already a few weeks I'm trying to bring up a solution of the USB Host via USB HS module with internal FS PHY. The same code works fine if I use OTG_FS module, once I pass to OTG_HS I'm starting to get a strange behavior which to my observation depends on some internal timing. I managed to get external device connection and exchanged a first SETUP read packet. But suddenly I found out that from time to time (about 10-20s not persistent) my OTG_HS host sporadically issues a RESET condition on the USB bus. I have seen 4ms drop on DP signal. After that I changed a bit an initialization sequence and got to the situation where OTG_HS can't properly detect device connection. It does detect but after some huge time of a 10-20min. GINTSTS also gives me a strange values that I can't explain. Below is the current initialization code. I do not use STM library but I went over library code and did exactly the same. (My initial version of the initialization works better but results in sporadic bus resets). This version has a detection problem so far./*
* IO & Clock Init
*/
if( REGS == USB_HS_REGS )
{
#ifdef CM5
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOBEN; /* Enable GPIOB Clock */
/* PB15 DM(D-), PB14 DP(D+) */
gpio_port_init( GPIOB, _IO(14)|_IO(15),
GPIO_MODE_ALT|GPIO_OUT_100M|GPIO_OUT_PP|GPIO_PULL_NO );
gpio_port_AF ( GPIOB, _IO(14)|_IO(15), AF_OTG_HS );
#endif
/* HS Module Clock Init */
RCC->AHB1ENR |= RCC_AHB1ENR_OTGHSEN;
}
else
{
#ifdef CM5
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; /* Enable GPIOA Clock */
/* PA11 DM(D-), PA12 DP(D+) */
gpio_port_init( GPIOA, _IO(11)|_IO(12),
GPIO_MODE_ALT|GPIO_OUT_100M|GPIO_OUT_PP|GPIO_PULL_NO );
gpio_port_AF ( GPIOA, _IO(11)|_IO(12), AF_OTG_FS_HS );
#if 0
/* PA10 ID */
gpio_init( GPIOA,10,
GPIO_MODE_IN|GPIO_OUT_100M|GPIO_OUT_OD|GPIO_PULL_UP );
gpio_AF ( GPIOA,10, AF_OTG_FS_HS );
#endif
#endif
/* FS Module Clock Init */
RCC->AHB2ENR |= RCC_AHB2ENR_OTGFSEN;
}
RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN; /* Used for EXT INT Control */
/* Init Global AHB Configuration Register */
REGS->GREGS.GAHBCFG = 0; /* Disable USB Int */
REGS->GREGS.GUSBCFG |= GUSBCFG_PHYSEL; /* USB 1.1 Full-Speed */
/* Core SW Reset */
usb_core_sw_reset( REGS );
/* Deactivate Power down */
REGS->GREGS.GCCFG = GCCFG_PWRDWN|GCCFG_NOVBUSSENS;
vTaskDelay( 20/portTICK_RATE_MS );
/* Force Host mode */
REGS->GREGS.GUSBCFG |= GUSBCFG_FHMOD; /* Force Host Mode */
/*
* After setting the force bit, the application must wait at least 25 ms
* before the change takes effect.
*/
vTaskDelay( 50/portTICK_RATE_MS );
/* PHY Clock */
REGS->PCGCCTL=0; /* UnGate the PHY Clock */
vTaskDelay( 20/portTICK_RATE_MS );
/* Init Host Configuration Register */
REGS->HREGS.HCFG = HCFG_FSLSPCS_48; /* FS,CLK:48MHz */
usb_host_port_reset( REGS ); /* Reset port */
#if 0
REGS->HREGS.HPRT = HPRT_PPWR; /* Poweron Host port */
vTaskDelay( 50/portTICK_RATE_MS );
#endif
/*
* Configure IRQ
*/
REGS->GREGS.GINTMSK = 0; /* Mask all general INTs */
/* Configure NVIC */
if( REGS == USB_HS_REGS )
{
NVIC_SetPriority( OTG_HS_IRQn, IRQ_PRI_USB_HS );
NVIC_EnableIRQ( OTG_HS_IRQn );
}
else
{
NVIC_SetPriority( OTG_FS_IRQn, IRQ_PRI_USB_FS );
NVIC_EnableIRQ( OTG_FS_IRQn );
}
My code is waiting for Port Change IRQ but right now the GINTSTS = 0x14008
I do not understand why I get such a strange flags. USB device is connected to port.
Any help would be highly appreciated.
2015-01-27 11:00 AM
It turns out that I had to enable Port Power:
REGS->HREGS.HPRT = HPRT_PPWR; /* Poweron Host port */
I also had to add 200ms delay after turning on OTG_HS clock.RCC->AHB1ENR |= RCC_AHB1ENR_OTGHSEN;
vTaskDelay(200)Without it access to OTG_HS registers did not work properly. I was checking the registers value and it was different from the written values.Can someone explain it?Now I keep getting sporadic USB bus RESETS generated by OTG_HS Host module.What an be a reason for such behavior?Thanks.2015-02-16 11:58 PM
After a few weeks of nightmare I have finally found that the issue is related to ST bug with sleep mode. It turns out that internal FS PHY on HS Module requires a special treatment when entering power saving mode.
WHY THIS IS NOT SPECIFIED IN ERRATA ?
2015-02-17 12:07 AM
Now to my next issue.
1. Upon receipt of the NAK event on Host IN Channel I read HCCHAR and see that the channel is still enabled - CHENA bit is set.Why?
Regardless to it I write CHENA=1 to HCCHAR and it does IN retry.2. Upon receipt of the NAK on Host OUT Channel, again I get CHENA set in HCCHAR but this time writing CHENA=1 does not lead to OUT retry. So actually I can't recover after OUT NAK. What can be a problem?
So far all my posts in this thread are neglected by ST support stuff and I have to talk to myself and find a solutions on my own. Can someone please put attention to my requests? Your timely help could save me a number of working weeks.
Thanks.2015-02-17 06:55 AM
Hi xol.xol
We are really sorry for the delay, we have been under big pressure to handle many urgent support requests coming in same time.I'm trying to reproduce the issue and will be back to you with some feedbacks.Best regards,Heisenberg.2015-02-22 10:56 PM
Any news?
I can not wait so long. We need to go on with a project. Maybe I can get a direct contact to someone in ST for help?2015-02-24 01:46 AM
Hi xol.xol,
In your application does the STM32F2 core go into low power mode ?Regards,Heisenberg.2015-02-24 09:42 PM
Hi,
Yes it does.But I already wrote that I've added (classified and never mentioned in ST documents) a magic line:/*STM32(Forum)
* When working with OTG_HS peripheral in FS mode and you want to enter* SLEEP using WFI cortex-M low power mode, the firmware side should configure* these bits in this way :* 1) Clear bit OTGHSULPILPEN in register AHB1LPENR* 2) Set bit OTGHSLPEN in register AHB1LPENR (already set after reset)*/RCC->AHB1LPENR &= ~RCC_AHB1LPENR_OTGHSULPILPEN;
2015-02-25 07:18 AM
Hi xol.xol,
In this condition there are some workaround to do, you already found it.We are aware of this issue, and it will be fixed in next releases.Thank you,Heisenberg.2015-02-25 09:14 PM
Thanks,
But you did not answer my following questions. Even after workaround was applied I still have below issues:1. Upon receipt of the NAK event on Host IN Channel I read HCCHAR and see that the channel is still enabled - CHENA bit is set.
Why?
Regardless to it I write CHENA=1 to HCCHAR and it does IN retry.
2. Upon receipt of the NAK on Host OUT Channel, again I get CHENA set in HCCHAR but this time writing CHENA=1 does not lead to OUT retry. So actually I can't recover after OUT NAK. What can be a problem?