---

grantb4 wrote:

Wouldn't that be a host bug?

---

Yah, it’s BIOS bug.
Try BIOS update, if any.
OR
Turn off "Legacy USB3.0 Support" on BIOS setting.

 

Tsuneo

---

I have discovered that my Full Speed HID device will hang a brand new Win7 PC on reboot

---

 

Where does the hang occur, BIOS or Windows?
Do you see Windows startup logo when hang occurs?

I believe Windows should hang, because BIOS ignores the HID device, unless it would assign boot protocol in the interface triad.

{ // interface_descriptor hid_interface_descriptor
   0x09,        // bLength
   0x04,        // bDescriptorType
   0x00,        // bInterfaceNumber
   0x00,        // bAlternateSetting
   0x02,        // bNumEndpoints
   0x03,        // bInterfaceClass (3 = HID)
   0x00,        // bInterfaceSubClass  <------ 0x00:No Subclass, 0x01: Boot Interface Subclass
   0x00,        // bInterfaceProcotol
   0x00         // iInterface
},

 

For Windows7, MS doesn't provide USB3.0 drivers, supplied by Intel in your case, ie. the manufacturer of the USB3.0 host controller. The USB3.0 drivers by manufacturers have been well established, but they differ slightly from MS original. This USB3.0 driver also affects to full-/low-speed device on the USB3.0 ports. Try driver update for any fix on this issue for your Intel chipset, for example

USB 3.0 Driver: Intel USB 3.0 eXtensible Host Controller Driver for Intel7 Series/C216 Chipset Family
https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=21129

---

grantb4 wrote:

The last "useful" transaction on EP0 is a SET IDLE (21 0A 00 00 00 00 00 00). 

---

This setup packet means Set_Idle(0); "indefinite" interval, which is always put by Windows at enumeration. In principle by this "indefinite" value, Windows expect a report, just when any change occurs. But actually, though it is bad practice, Windows should accept reports at every interval, even if they are identical reports. In this reason, report duration control have not been implemented positively.

 

---

grantb4 wrote:

Perhaps if your design NAKs on the data endpoints most of the time there is no issue?

---

I'm not sure NAKs would work around this issue (maybe not).
But if you would like to be in good practice, it's easy
Put to the interrupt IN endpoint, just when any change occurs on your firmware.
You should show the version of SiLabs library, for detailed discussion of the code.

Tsuneo

I picked up old SiLabs IDE (and examples) v2.61 from my archive.
Installed the IDE and tested USB_INT example on SiLabs 'F340 dev board.

Changing EP0_PACKET_SIZE down, the example firmware was enumerated at 64 (default) and 32 successfully on Windows 7 (x86), but it failed at 16. A STALL occurred at the second IN transaction (DATA stage) of Get_Descriptor( Device ). The next retry of Get_Descriptor( Device ) succeeded.

 

 

A couple of Get_Descriptor error were seen after above one. At last, Windows gave up enumeration.

I remember this timing issue is caused by too early asserting of DATAEND bit, while DATA stage still continues, caused by SUEND process. In this post, I described on this issue and its fix.
http://community.silabs.com/t5/8-bit-MCU/F32x-Fails-on-High-Speed-Hub/td-p/70031

Fix of this issue is,

F34x_USB_ISR.c
void Handle_Setup(void)
{
   ...
   if (ControlReg & rbSUEND)           // If last setup transaction was ended
   {                                   // prematurely then set
      POLL_WRITE_BYTE(E0CSR, rbDATAEND);        // <------------------ delete this line
      POLL_WRITE_BYTE(E0CSR, rbSSUEND); // Serviced Setup End bit and return EP0
      Ep_Status[0] = EP_IDLE;          // to idle state
   }

 
Deleting "POLL_WRITE_BYTE(E0CSR, rbDATAEND);" line from above code made the USB_INT example enumerated successfully on all of possible EP0_PACKET_SIZE (bMaxPacketSize0), 64, 32, 16 and 8, on my side.

Tsuneo

I remember,
the USB SIE on F32x/34x/38x has undocumented indexed registers, INMAX, OUTMAX
http://community.silabs.com/t5/8-bit-MCU/Optimization-of-SiLabs-USB-examples-in-code-size/m-p/69427#M28037

 

// USB Core Registers
#define BASE			0x00
#define FADDR			BASE
#define POWER			BASE + 0x01
#define IN1INT			BASE + 0x02
#define OUT1INT			BASE + 0x04
#define CMINT			BASE + 0x06
#define IN1IE			BASE + 0x07
#define OUT1IE			BASE + 0x09
#define CMIE			BASE + 0x0B
#define FRAMEL			BASE + 0x0C
#define FRAMEH			BASE + 0x0D
#define INDEX			BASE + 0x0E
#define CLKREC			BASE + 0x0F
#define INMAX			BASE + 0x10    // <--
#define E0CSR			BASE + 0x11
#define EINCSRL			BASE + 0x11
#define EINCSRH			BASE + 0x12
#define OUTMAX			BASE + 0x13    // <--
#define EOUTCSRL		BASE + 0x14
#define EOUTCSRH		BASE + 0x15
#define E0CNT			BASE + 0x16
#define EOUTCNTL		BASE + 0x16
#define EOUTCNTH		BASE + 0x17
#define FIFO_EP0		BASE + 0x20
#define FIFO_EP1		BASE + 0x21
#define FIFO_EP2		BASE + 0x22
#define FIFO_EP3		BASE + 0x23

 

While these registers are left in the default value (0), the SIE isn’t aware of Max Packet Size, at all. Actually, above F34x_MouseExample doesn’t touch to these registers.

If your stack would set up these registers, your stack could be set them wrongly.

 

Tsuneo

What is the USB stack on which you are working?

 

I tested F34x_MouseExample (Si8051 SDK v2.0.0) - Simplicity Studio v2, on SiLabs F34x dev board. It worked without any problem on 8, 16, 32 and 64 of bMaxPacketSize0

 

F3xx_USB0_InterruptServiceRoutine.h

// Define Endpoint Packet Sizes
#ifdef _USB_LOW_SPEED_
#define  EP0_PACKET_SIZE         0x08  // This value can be 8,16,32,64
                                       // depending on device speed, see
                                       // USB spec
#else
//#define  EP0_PACKET_SIZE         0x40
//#define  EP0_PACKET_SIZE         0x20
//#define  EP0_PACKET_SIZE         0x10
#define  EP0_PACKET_SIZE         0x08
#endif /* _USB_LOW_SPEED_ */

 

Tsuneo

Not so much any more.

SiLabs have opened FLASH programming protocols over JTAG and C2 interfaces.
AN105 Programming FLASH through the JTAG Interface
F12xJTAGProgramming.zip attached to this MCU KB
AN127 FLASH Programming via the C2 Interface and AN127SW.zip

Thanks to Matt Otto, most of C2 debug stuff has been revealed.
c2_prog2.tar.bz2 on Wojtek page.

It worked well. I've also used the information to play with SiLabs C2 MCUs.
Locking RAM access through C2 dbg IF

The rest is just matching it to gdb, etc.

I don't agree with the EC2DRV project, because they've tried to trace EC2/EC3 (USB one) protocol, which SiLabs have often changed with the firmware update of the adapters.
They stick to use EC2/EC3 as is, but it's better to make up their own adapter, or even their own firmware FLASHed to EC2/EC3. And then, the project would have survived, without so much update.

Tsuneo

[This message has been edited by Tsuneo (edited December 16, 2009).]

SiLabs IDE is a MDI (Multi-Document Interface) application with docking panes. The watch window (pane) should be displayed somewhere in the parent window.
It may be shrunk because so many panes (disasm window and other debugger windows) are displayed on the parent window. Close other panes temporarily, and the watch window will be displayed.

Tsuneo

for the assemble I have blinky.asm
In the left hand box (project files) I have
blinky.c and bliny.asm for assemble and compile but only blinky.rel for the linker option.

You don't need to register blinky.asm which is generated by the compiler, in either pane. Register just the original source file, either C or asm


My other question was getting the editor to display line numbers, is that possible?

Maybe not.

I'm usually using UltraEdit for coding.

Tsuneo

[This message has been edited by Tsuneo (edited April 04, 2008).]

Hello mike,

The flags in the tool chain are fine.
Absolute OMF file name doesn't need any extension.

a) Is there any compile error message?
Scroll the bottom Build message pane of the IDE and find error messages.

b) Are all of .c and .asm files on the left pane assigned to Build (with down arrow mark)?

Tsuneo

for the assemble I have blinky.asm
In the left hand box (project files) I have
blinky.c and bliny.asm for assemble and compile but only blinky.rel for the linker option.

You don't need to register blinky.asm which is generated by the compiler, in either pane. Register just the original source file, either C or asm


My other question was getting the editor to display line numbers, is that possible?

Maybe not.

I'm usually using UltraEdit for coding.

Tsuneo

[This message has been edited by Tsuneo (edited April 04, 2008).]