USB on single target, on IAR debugger EPxRegs arre reset

[benoit239955_stm1_st]

Posted on April 13, 2010 at 15:44

USB on single target, on IAR debugger EPxRegs arre reset

#stm32-usb

[benoit239955_stm1_st]

Posted on May 17, 2011 at 13:46

The EPxRegs can be modified if Resume bit is set to 1. Else, registers are not accessible????

[picguy2]

Posted on May 17, 2011 at 13:46

I have what looks like the same problem.  Both the endpoint registers and the memory map addresses always revert to zero in my driver.  (The other registers seem to be okay.)  Needless to say my driver is far from working.  HOWEVER, using ST’s code without mods these registers work using IAR tools and the yellow jlink.

I’ve tried incorporating much of ST’s setup code in order to debug my stuff.  Because nobody is yet paying me for my 32-bit code I switched over to 8-bit code to write something I can get paid for.

If anyone has any clues to what I could be doing incorrectly I would be grateful.  

Both of my planned USB drivers are intended to be 100% interrupt driven save for setup.  Background code wanting to write (IN transaction) sets a few bytes of memory and causes an interrupt.  Reads from the host (OUT transactions) are setup the same way.  Both forms return status info for the background code.

[t1_it]

Posted on May 17, 2011 at 13:46

Yes STMicroelectroncs, under what circumstances do the endpoint registers refuse to be initialized?

I have a program that works and a program that doesn't work and it is not at all clear what makes the difference.

[picguy2]

Posted on May 17, 2011 at 13:46

I had the USB_CNTR resume bit zero.  I will try setting resume and report back - hopefully in a few days.  guibert.benoit, if you have resume=0 and changing it works please report back here.

Right now my mind and debug tools are setup ready to try yet another iteration of Sweet Home Pellet Grill 16F884 firmware.  It works with pellet stove fuel but has trouble with the near infinite variety of “BBQ flavor�? fuels.  My latest tweak may work.  Fingers crossed....

[benoit239955_stm1_st]

Posted on May 17, 2011 at 13:46

The RM0008 documentation has on 21.4.2 a specific sequence to power on the USB. This sequence is not executed by the samples programs  delivered with the USBlib.

Furthermore at the 12th line, the PWDN has to be set or reset it is not clear.

It is not the USBLIB code has been tested in device mode because there is no KIT delivered with USB device. All kits i find are for OTG and it is not the same firmware.( I expect one kit with the right device to morrow.)

A documentation for the USB library should be welcome (at the same level than the FWLIB)

I continue !!!

[Nickname12657_O]

Posted on May 17, 2011 at 13:46

Hi ,

USB Registers and PMA memory is accessible only when 48MHz Clock of the Analog engine is enabled, APB Clock is enabled and not in reset mode and finally of course when the USB Peripheral is enabled by software,  For more details regarding registers refer to our RM0008 Reference Manual.

I would suspect that in your case to check that all clocks are enabled and USB is active.

Hope this helps you.

Cheers,

STOne-32.

[Nickname12657_O]

Posted on May 17, 2011 at 13:46

Hi Guibert,

All our code dealing with USB Power and enable is inside this file

''usb_pwr.c'' , you can explore functions like : PowerOn, PowerOff , Suspend etc...

There are also calls to functions like  ''Enter_LowPowerMode();''  defined in hw_config.c file and depends on your board implementation.

Cheers,

STOne-32.

[t1_it]

Posted on May 17, 2011 at 13:46

''check that ... USB is active.''

Can the USB be enabled but inactive; and in the inactive state the endpoint registers cannot be set?  Does setting the resume bit make an inactive USB active?

[benoit239955_stm1_st]

Posted on May 17, 2011 at 13:46

If the DP and DM are in SE0 state, registers are not accessible (in continuous reset?). I use a tranceiver with integrated pull down on down stream signals. The problem is fixed with a 1.5K pull up on DP-STM32. (The pull up on DP-USB is lock to 0).

If the CAN1/2 are not reset, shared SRAM is not accessible. Problem fixed by desinit CANx.

Now it is OK.