cancel
Showing results for 
Search instead for 
Did you mean: 

first SETUP packet on otg-hs ulpi interface TXERR

shark
Senior
Posted on March 28, 2013 at 06:28

hardware: STM32-407VG, ulpi phy usb3300, power switch MIC2026-2BM

software: modified from stm324xG-EVAL_USBH-HS v2.1.0, forced in host mode.

success 1. The code runs well on otg-fs core, mass-storage device is enumerated successfully. so the code is almost bug-free. all the following success and failures are happened on hs core with ulpi interface.

success 2. On the otg-hs core, I can turn on/off port power successfully via USB_OTG_DriveVbus()

success 3. Usb device insertion/remove can be detected by code successfully.

success 4. The usb RESET signal is sent out, and high speed device is detected successfully by code. it can been proven through usb wire analyzer too.

failure 5. the first SETUP packet can NOT been sent out. the channel interrupt

register HCINT bit 7 TXERR is always 1, the 3 times halt and retry failed too.

  hcreg = pdev->regs.HC_REGS[num];

  hcint.d32 = USB_OTG_READ_REG32(&hcreg->HCINT);

  hcint.b.xacterr is always 1

success 6. I put something onto 3.3V power supply for a short time by accident, resulting the stm32 to reboot, usb3300 should be reset too. Now the code enumerate the high speed device successfully! this situation can be repeated many times.

failuer 7, after previous success 6, I reboot the stm32 by code NVIC_SystemReset(), situation goes to failure 5 again.

What is the cause of HCINT bit 7 TXERR? Can the success 2-4 prove that the ulpi data bus between stm32 and usb3300 works well? the success 6 and failure 7 are strange.

The communition between stm32 and usb3300 is not opened to software, it is difficult to guess the problems inside it. If helpful for analyze, I can show you all the usb registers's content before sending first packet.

I was blocked here for 2 weeks, please help me.

#usb-host-otg-hs-ulpi
1 REPLY 1
shark
Senior
Posted on September 28, 2014 at 11:59

The demo source code lacks 2 line:

the demo version v1.3.0,

c source code usb_bsp_eval.c,

function void USB_OTG_BSP_Init(USB_OTG_CORE_HANDLE *pdev)

...

  else if (pdev->cfg.coreID == USB_OTG_HS_CORE_ID)

{

...

    // CLK

    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5 ;

    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;

    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;

    GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;    // add here

    GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL ; // add here

    GPIO_Init(GPIOA, &GPIO_InitStructure);

    // D0

...

The clock pin is in random state, so anything can happen.The stm32cube_fw library is correct now.