To build DE3:

1. Open a BASH window Start → Programs → Cypress → BASH → EnvironmentOTG — Host → USB
2. Change directories to DE3
   [cy]$ cd Source/stand-alone/de3
3. Do a make clean to start from scratch
   [cy]$ make clean
4. Do a make all to rebuild all code
   [cy]$ make all

To download the code to the EZ-Host Development Board RAM:

1. Open a BASH environment and go to the de3 directory
2. Use a text editor to view de3.ld to see where the code is org’d at (. = 0x####)
   [cy]$ cy16-elf-objdump –f de3
   [cy]$ cy16-elf-readelf –h de3
   [cy]$ head -20 de3.ld
3. Run scanwrap on the binary image
   [cy]$ scanwrap de3.bin de3_scan.bin 0x04A4

To download the code to the EZ-Host Development Board EEPROM:

1. Set all of the board’s dipswitches to off
2. Power up the board by plugging in the power connector
3. Reset the board by pressing the reset button
4. Set the dipswitches for EEPROM 4/stand-alone mode
5. Open a BASH window and go to the de3 directory
6. Plug in a USB cable to SIE2 (Peripheral–2A)
7. Verify the device manager is using the correct driver
   Cypress USB EZ-OTG Device VID=04B4, PID=7200
8. Run qtui2c
   [cy]$ qtui2c de3_scan.bin f

Reprinted with permission from Electronic Design,
June 10, 2002. Copyright 2002, Penton Media Inc.
611 Route 46 West, Hasbrouck Heights, NJ  07604, USA

Read the article here.

For more information on our USB Embedded Hosts products, visit: cypress.com

The new EZ-811HS (CY3662) development platform provides the most flexible development environment for embedded host applications. The EZ-USB(R) development kit is the ideal starting platform for SL811HS development, using the internal 8051 core as the microcontroller unit (MCU) interface to the SL811HS and the EZ-USB interface for debugging purposes.

The EZ-811HS kit includes the EZ-USB base board and the SL811HS embedded host daughter card, plus a generic mini-port driver that lets you develop simple code to interface to a variety of microprocessors and target peripherals. Real-time operating system (RTOS) drivers are also available for VxWorks, Linux and Windows CE 3.x.

• Single chip programmable USB dual-role (Host/Peripheral) controller with two configurable Serial Interface Engines (SIEs) and four USB ports
• Support for USB On-The-Go (OTG) protocol
• On-chip 48 MHz 16-bit processor with dynamically switchable clock speed
• Configurable IO block supporting a variety of IO options or up to 32 bits of General Purpose IO (GPIO)
• 4K x 16 internal masked ROM containing built in BIOS that supports a communication ready state with access to I2C(TM) EEPROM Interface, external ROM, UART, or USB
• 8K x 16 internal RAM for code and data buffering
• Extended memory interface port for external SRAM and ROM
• 16-bit parallel Host Port Interface (HPI) with a DMA/mailbox data path for an external processor to directly access all of the on-chip memory and control on-chip SIEs
• Fast serial port supports from 9600 baud to 2.0M baud
• For more, see pdf
   

Introduction

EZ-Host(TM) (CY7C67300) is Cypress Semiconductor's first full-speed, low cost multiport host/peripheral controller. EZ-Host is designed to easily interface to most high performance CPUs to add USB host functionality. EZ-Host has its own 16-bit RISC processor to act as a coprocessor or operate in standalone mode. EZ-Host also has a programmable IO interface block allowing a wide range of interface options.      More...

Features

• First USB Host/Slave controller for embedded systems in the market with a standard microprocessor bus interface
• Supports both full speed (12 Mbps) and low speed (1.5 Mbps) USB transfer in both master and slave modes
• Conforms to USB Specification 1.1 for full- and low speed
• Operates as a single USB host or slave under software control
• Automatic detection of either low- or full speed devices
• 8-bit bidirectional data, port I/O (DMA supported in slave mode)
• On-chip SIE and USB transceivers
• On-chip single root HUB support
• 256-byte internal SRAM buffer
• For more, see pdf
   

Introduction

The SL811HS is an Embedded USB Host/Slave Controller capable of communicating in either full speed or low speed. The SL811HS interfaces to devices such as microprocessors, microcontrollers, DSPs, or directly to a variety of buses such as ISA, PCMCIA, and others.

Features

• Single-chip programmable USB dual-role (Host/Peripheral) controller with two configurable Serial Interface Engines (SIEs) and two USB ports
• Supports USB OTG protocol
• On-chip 48-MHz 16-bit processor with dynamically switchable clock speed
• Configurable IO block supports a variety of IO options or up to 25 bits of General Purpose IO (GPIO)
• 4K × 16 internal mask ROM contains built-in BIOS that supports a communication-ready state with access to I2C(TM) EEPROM interface, external ROM, UART, or USB
• 8K x 16 internal RAM for code and data buffering
• 16-bit parallel host port interface (HPI) with DMA/Mailbox data path for an external processor to directly access all on-chip memory and control on-chip SIEs
• Fast serial port supports from 9600 baud to 2.0M baud
• SPI supports both master and slave
• For more, see Pdf
   

Functional Description

EZ-OTG(TM) (CY7C67200) is Cypress Semiconductor's first USB On-The-Go (OTG) host/peripheral controller. EZ-OTG is designed to easily interface to most high-performance CPUs to add USB host functionality. EZ-OTG has its own 16-bit RISC processor to act as a coprocessor or operate in standalone mode. EZ-OTG also has a programmable IO interface block allowing a wide range of interface options.      More...

Driver Signing for Windows Hardware Certification

A complete beginning-to-end walkthrough of how to digitally sign drivers is provided by Microsoft and is available at http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx

FAQs

Question 1: I get the following error while binding my device to CyUSB.sys in Windows 7/Vista 64-bit environment, “Windows encountered a problem installing the driver software for your device” or usage of CyUSB.sys in Vista 64-bit operating system gives Code 39 error (Code 52 in the case of Windows 7). What do these errors mean? How can they be resolved?

Answer: CyUSB.sys downloaded through our website is an unsigned driver. This error reported while an unsigned driver used in 64-bit operating systems in normal mode. Following are the steps to disable driver signature enforcement in 64-bit operating system:

a) During boot-up press F8.

b) In the list of options that appear select “Disable driver signature enforcement”.

This should resolve the issues.

Note: In the case of Windows Vista 64-bit operating system the error message is “Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39)”. In the case of Windows 7 64-bit operating system it is "Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)".

Question 2: What is the signing procedure when script files are used?

Answer:When script files are used, the Inf file should contain both VID/PID combinations while signing the driver. The procedure for signing the procedure is the same as that for regular drivers. The script file (.spt file) will need to be shipped along with the Inf/Sys files.

The EZ-OTG(TM)/EZ-Host(TM) Development Kit contains all the key elements required to get an embedded host or On-The-Go system up and running. Cypress understands the importance of time-to-market and a minimal learning curve for new technology. The development kit includes multiple design examples that illustrate all primary usage models of the chip. Complete source code, intended for reference and reuse, is included for all components. 

The kit features: 

• Development boards for both EZ-OTG and EZ-Host
• Design examples for primary usage modes
  • Designs illustrate:
    • USB On-The-Go
    • Multiport host
    • Peripheral mode
    • Simultaneous host and peripheral operation
  • Design example components
    • Windows-based tutorial and control panel application
    • EZ-OTG/EZ-Host firmware
    • Linux firmware for StrongArm 1110
• CY16 processor development tools
  • Eclipse IDE (Integrated Development Environment)
  • Compiler
  • Assembler
  • Linker
  • Debugger
  • Multiple binary utilities
• Linux OS support on the StrongArm
  • Linux USB Stack
  • Cypress provided drivers for:
    • Host support
    • Peripheral support
    • OTG support
• Complete documentation
  • Data sheets
  • Usage guides for all software components
  • Hardware design materials
    • Schematics
    • Bill of Materials
    • OrCAD source
    • Gerber databases

The downloads listed below include: 

• Individual key documents
• Entire CY3663 documentation package (zipped)
• Zipped hardware reference files (Schematics, BOM, gerber files, and OrCAD files)

Related Links
Complete (278 MB) Development Kit CD-ROM image
Java Runtime Environment for the Eclipse IDE
EZ-OTG/EZ-Host Windows CE driver.

1. The SL811HS is a Serial Interface Engine [SIE] only device [no internal processor]. This would mean that it would only handle the low level USB transactions like bit stuffing, ser-deserializing, CRC functions and the like [protocols]. Certainly it would detect device insertion and removal but this would to a very large extent be firmware dependent as well. On the contrary, the OTG-HOST [comprising of the CY7C67200 and the CY7C67300] has an internal CY16 RISC processor [16 bit enhanced] that would be basically used for processing the code in standalone mode and frees up the external processor for other tasks.

2. This would certainly put the point across that the SL811HS is inherently a 8 bit controller as opposed to the 16 bit processing power of the OTG-HOST.

3. The SL811HS has 256 bytes of internal RAM for the control registers and buffers. The CY7C67200 has 16KB of internal RAM [no external interface available] and the CY7C67300 has 16KB of internal RAM with external memory interfacing available. This is one of the major differences between the CY7C67200 and the CY7C67300.

4. The SL811HS does not have the OTG [On the Go] functionality which is present in the OTG-HOST.

5. The OTG-HOST can operate either in standalone mode where the firmware is downloaded over EEPROM or one of the co-processor interfaces [HPI, SPI or HSS]. The standalone mode is not possible using the SL811HS and neither does it support these interfaces.

6. The SL811HS has a single SIE with a single USB port. The OTG-HOST has two configurable SIE's with 2 usb host ports for the CY7C67200 and 4 usb host ports for the CY7C67300, with the additional single OTG port for both the parts. This makes design using the OTG-HOST parts very flexible.

7. Battery operation is possible using the booster circuit in the OTG-HOST parts. This is not possible in the SL811HS.

1. When BIOS first starts executing and does initialization, it will try and see if a 16-bit RAM is connected to the external memory bus. It does this by writing and reading a value of 0x6000 on the external memory bus. You could probe for this write. The BIOS will also perform an external read to 0xC100 (should do this prior to writing the 0x6000 for the 16-bit RAM test).

2. The qtuarena or qtsarena tools could be used to talk directly to the BIOS. These tools are explained in the CY16 Binary Utilities.pdf in the C:\Cypress\USB\OTG-Host\Docs directory.

Practical throughputs will vary around 200KBPS - 1MBPS .It depends on mostly firmware overhead which largely depends on type of applications like mass storage-CF , MP3 , IDE interfaces, Class devices. To list some of the factors of firmware that affect throughput:

1. Standard USB request processing + Class requests (mass storage,audio , printer class etc)

2. Communication interfaces like
SPI Slave:  1-2 Mbps
SPI Master: 12 Mbps
HSS: 2Mbps
HPI: 16MBps
UART: 115 Kbps

With slower communication interfaces, the processor should share the load between interface and the USB bus.  This will reduce the throughput drastically. With faster communication interfaces the throughput will be near to max limit. In this case it depends on the user code design here to get better throughput.

Although the hub is synchronized to the SOF, timing skew can accumulate between the host and a hub. The total accumulated skew can be as large as ?9 bit times. Beyond that the hub may stop working.

So when sharing an SIE for two host ports, Host n SOF/EOP Count Register (0xC092 and 0xC0B2) for this SIE shouldn't be written when a new device is inserted. The default value (0x2EE0) will be used in this case. If you are using the ISR HUSB_RESET when you get an insert, the HUSB_RESET will write to this register and can cause the problem.

The corrective action for this issue is to NOT write to the "Host n SOF/EOP Count Register" when you have a hub on that SIE - or at all for that matter. Leave the value as the default 0x2EE0. If you need to call the USB Reset function in the BIOS, then you may need to write your own USB Reset handling routine based on our BIOS code, but removing the write of the Host n SOF/EOP Count Register.

If you purchase a CY3663 - EZ-OTG / EZ-Host Development Kit, you get hardware that can be used to do the development in either co-processor or stand-alone mode. You get both EZ-Host and EZ-OTG boards along with a StrongArm board that runs Linux to demonstrate the co-processor portion. You can download all the documentation and actually the CY3663 CD-ROM image  from our web site and install the tools without purchasing a kit but without the hardware you can only do so much. Because of the flexibility of the part there is a lot of documentation, which can be a little overwhelming so be warned. When the software is all installed you will find 4 main design examples that are good starting points for almost any design.

There are also several simple examples used in conjunction with the book written by John Hyde called USB Multi-Role Device Design By Example, which is in the kit's Docs directory, used to demonstrate various functions of the part and tools.

 The recommendation would be to first go through the OTG-Host Navigator tutorial, which is started from the Windows Start | Program Files | Cypress | USB | OTG-Host | OTG-Host Navigator. This tutorial will walk you through the 4 design examples already mentioned. Next it is a good idea to read through the USB Multi-Role Device Design By Example and use the examples to understand the part and the tools. From here you will find the key documents you will need are 1) the datasheet  and 2) the BIOS Users Guide, which is also found in the Docs directory.

If a GPIO pin is set as an input, simply read the contents of the GPIO n Input register. All Inputs are sampled asynchronously with state changes occurring at a rate of up to two 48-MHZ clock cycles. GPIO pins are latched directly into registers with a single flip-flop. As an output simply write to the GPIO n Output Data Register. As an example to demonstrate both outputs and reading an input try the following using qtudump. 

If we want 3 GPIO pins to be outputs (let's say GPIO 2:0) then you would set the GPIO 0 direction register (0xC022 to 0x0007). Type in the following from a BASH shell prompt with your board connected : [cy]$ qtudump 0xC022 w 0x0007.

Now GPIO[2:0] are defined as outputs. Since the GPIO 0 Output Data Register by default is set to 0x0000, GPIO[2:0] should all go low. You can read these values by reading the GPIO 0 Input Data Register by doing a qtudump 0xC020 1 from the BASH shell prompt ([cy]$ qtudump 0xC020 1).

To make one output go high simply write to the GPIO0 Output Data Register using bash  shell command([cy]$qtudump 0xC01E w 0x0001) and the output should go high.Again a read should show the current value of the pin ([cy]$qtudump 0xC020 1).

Co-processor mode:  In this mode you would use an external processor in conjunction with the internal CY16 processor through one of the 3 processor interfaces available in the CY7C67200/300. The most popular interface is the HPI bus because of its speed and flexibility. In co-processor mode the external processor is typically running an RTOS such as Linux or WinCE. The CY3663 - EZ-OTG / EZ-Host Development Kit does include a Linux driver for our parts and an EZ-OTG/EZ-Host Windows CE.NET driver is available on our web site. A driver would need to be developed for other RTOSs. The advantage to using an RTOS is the access to other class drivers. You would need to contact the provider of the RTOS you are using to determine if a driver is available for your target device. 

Stand-alone:  In stand-alone mode the internal CY16 processor is typically the only processor in the solution. In this case firmware is loaded into the part from an EEPROM at power up. When operating in stand-alone you will need to build your own driver that applies to the target device you want to host or internal firmware for being a slave. We do not have class drivers for a Palm in our frameworks code at this time although Cypress has had customers who have used these parts for hosting Palm PDAs. In the CY3663, there are several design examples that are typical to a given design and a customer will normally start from the one that most closely matches their design. They then will use the driver template and develop the driver for their TPL (Targeted Peripheral List).

Most customers who start with the Sun version first without success will have better luck with the IBM JRE. You can download a copy of the IBM version from our web site at: http://www.cypress.com/?rID=14437

As a suggestion, another resource for eclipse questions can be directed at http://www.eclipse.org./ It has been reported that the newer version of Eclipse operates better with either of the JREs.

The CY3663 DVK contains design examples which require the SBC for some of the examples to operate. Also include is a book written by John Hyde, which contains several simple examples used to demonstrate various OTG-Host concepts. Some of these simple examples require the SBC to complete.

The CY3663 DVK comes with the SBC and two mezzanine boards for maximum configurability by the user. These mezzanine boards cannot be purchased separately although there is another option for those who want to run only in a stand-alone mode. This is to purchase the CY4640, which is a mass storage reference design. This board is very similar to the EZ-Host mezzanine board in the CY3663. The key difference in the boards is the fact that the CY4640 has some of the parts physically removed although the pads are still available for re-populating the board. These parts are not necessary for the CY4640 and may not be necessary for your design either. The document called CY4640 Hardware User Manual is included in the CY4640 documents describes the components that are not loaded.

Keywords:
CY7C67200, CY7C67300, EZ-OTG, EZ-Host, CY3663, CY4640, mezzanine board, Linux

ID: VCS05050502

Response:If operating EZ-Host or EZ-OTG in peripheral mode and the peripheral is configured for ISOCHRONOUS endpoints you may see this problem. For an ISOCHRONOUS endpoint, if the bmAttributes field in the Endpoint Descriptor is using bits 5..2, which is valid, the BIOS will not correctly parse the endpoint and set up the part correctly for ISO transfers.

There are two ways to address this issue. One method is to mask these bits before the BIOS parses the descriptors. Since there will be multiple interfaces with an ISOCH solution, you can mask the bmAttributes in the SET_INTERFACE handler. This is actually demonstrated in the application note titled: Using Multiple Interfaces to Implement a USB Isochronous Composite Peripheral with EZ-Host(TM) and EZ-OTG(TM) - AN5083. An alternate solution would be to replace the BIOS delta config interrupt and modify the USB_parse code to mask off all but the lower two bits of the bmAttribute (for bEPAttribute). A copy of the BIOS source code can be requested from Cypress Technical support. A possible solution in the BIOS code might look like this:

Currently in the BIOS USB_parse you will find this:

@@:  cmp b[r8+bEPAttribute],1      ; check ISO

          rne

          or  r2, EP_ISO

          ret

The cmp statement checks to see if the bEPAttribute equals 1. To resolve this issue, you can check that only the lower two bits equal 01b and ignore the upper bits. Your code could look something like this:

@@:   test  b[r8+bEPAttrigute], 0x01    ; check ISO

          rz

          test   b[r8+bEPAttribute], 0x02

          rnz

          ; if we get here, then the lower two bits of bEPAttribute = 01 meaning it is ISO

          or  r2,EP_ISO

          ret

B6 C3 03 00 09 3A 22 22  (Note the byte swap for the little endian)

C3 B6 - is the scan signature
00 03 - is the length after the OpCode
09 - is the OpCode for Write Configuration
3A - is the configuration address (adds 0xC000 because this is the configuration space)
22 22 - is the data that will be written to address 0xC03A.

So the parsing routine would recognize the scan signature as being valid and would know how long the actual data is going to be. It will then recognize that this is to write a configuration register and has the register address and data that needs to be written. Then over the co-processor interface it will use the equivalent LCP command. In this case it would equate to a COMM_WRITE_CTRL_REG LCP command. The application can then continue parsing through the scan wrapped image until it has downloaded the complete image and started execution of the code at the starting location of the firmware image.

Check the Cypress web site for updated application notes that address this topic in more detail.

However, the OTG-Host products can also operate in a mode where standalone code is running on the OTG-Host and is communicating over the coprocessor interface to an external master.

1. SCAN_INT as Interrupt 67 at vector location 0x86

2. SCAN_DECODE_INT as Interrupt 79 at vector location 0x9E

During Boot up time BIOS will utilize signature SCAN features in the following way:

1.   Read External ROM location 0xC100 for SCAN signature 0xC3B6.If it exists BIOS will jump to the location following the signature  for the entire BIOS override.

2.   Reads the EEPROM through I2C for SCAN signature 0xC3B6. If it exists the subsequent SCAN records are read sequentially and the entire firmware image is copied from EEPROM to on-chip RAM at start_addr mentioned in the SCAN record.

3.   At the end of BIOS initialization BIOS creates usb_idle and uart_idle tasks. uart_idle used for debugging through COM port and usb_idle to download firmware image into EEPROM. These tasks run concurrently in the background and call SCAN interrupt if 0xC3B6 is decoded in the UART/USB packets.

Using scanwrap.exe utility of CY3663 DVK the firmware image xxxx.bin is converted to scan_xxx.bin .This image contains SCAN records inserted between data. The image is downloaded into EEPROM in standalone mode .During boot up BIOS checks the EEPROM for SCAN records in this image.

The image contains SCAN records in the below format

Record1:

0xC3B6-0xnnnn(data length)-0xmm(SCAN opcode) – data_0....data_n 

Record2:

0xC3B6-0xnnnn(data length)-0xmm(SCAN opcode) – data_0....data_n 

Last Record:

0x00 0x00

There are 10 SCAN opcodes for different functionality. Method of interpreting the data bytes depends on SCAN opcode number. SCAN_DECODE_INT interrupt will decode the SCAN record to find the relevant opcode. simple examples (se2,se8) utilize SCAN opcodes 0 and 4 to skip SIE1/SIE2 hardware initialization in BIOS. For I2C download SCAN opcode 7 and 8 are used.

Refer the following documents for detailed description,

1.   USB Multi-Role Device Design By Example.pdf: Page 34-35

2.   OTG-Host BIOS User Manual.pdf :pages 35-39

Both the documents can be found at C:\Cypress\USB\OTG-Host\Docs in CY3663 DVK .

There are 2 ways to communicate with the EZ-Host in co-processor mode.

Method 1 is as follows:

The external processor can send LCP commands to BIOS. The TD_list information is dumped into EZ-HOST memory which contains details about the set up phase, data phase and acknowleldgement phase of USB transactions. The LCP commands can be used by the external master to access any CPU register.

Here, triggering the BIOS through LCP and then sending TD_list information is sufficient.The OTG-Host device then transfers the data associated with this TD_List to or from USB.
This method eliminates the need of having USB Host stack (TD_list,urb,mass storage class or any class request info,File operations/FAT32 for mass storage etc) in EZ-HOST. BIOS will handle the entire function of decoding LCP commands.

Please refer to the attached appnote which explains TD_list preperation. You will also find chapter 3 of the attached document OTG-Host BIOS User Manual useful.

The Method 2 is as follows:

Download firmware from External processor to EZ-HOST memory through HPI,HSS and SPI.

Intially from GPIO[30:31] pins logic BIOS will decide to switch to any of the 3 SPI,HSS and SPI assembly routines in its ROM code . These routines have capability to understand and decode the content of LCP formatted commands.

Initially for firmware download, BIOS on EZ-HOST side will handle all relevant LCP commands . After download there is an LCP command to jump to the start of downloaded firmware sent by external processor .From this point the firmware will have control over the EZ-HOST chip.
Now user can implement the protocol of his choice (LCP or any other) in his firmware here to suit his end device connected to HOST port.

For example Cypress CY3663 DVK based EZ-HOST board has the following features

1. USB Ports:

    SIE1   -2 Host ports (HOST 1A, 1B), 1 Peripheral port (1A) and an OTG port.

    SIE2   -2 Host ports (HOST 2A, 2B) and 1 Peripheral port (2A).     

     These are the maximum USB ports interfacing available using EZ-HOST DVK.

2. Four i2c eeproms are added to allow flexibility to switch between different firmware images.

3. Using a 8 switch dip buttons user can manually select one of the eeprom to boot the image.

4. Additional cypress CPLD CY37064 to add more flexibility in controlling 

     a. Seven segment display
     b. 4on/off Push buttons

     c. Dip switch

     d. GPIO [30:31].

5. CY7C1021CV 64*16 ASYNC SRAM is added to provide external memory support for bulky applications (more than internal RAM size of 15K).

 CPLD based Seven segment display and On/Off push buttons are optional for customer designs. External memory support is needed only when size of the application firmware exceeds more than 15KB internal RAM size.

The current rating for the fuse F1 is 5A and the current rating for the 3.3V regulator used is 3A.

In our cyusb.inf we comment out the lines
CyUsb.GUID="{AE18AA60-7F6A-11d4-97DD-00010229B959}"
and
HKR,,DriverGUID,,%CyUsb.GUID%
to imply the fact that customer should use their own GUID for production even if cyusb.sys is used without modifying. 
In some releases of ours we would have not commented out these two lines. When one of these inf files is used the DriverGUID registry value is added in the registry. Which makes the device visible to the .Net interface.

i. Download to EEPROM: Using windows based bash shell utility(qtui2c.exe available in CY3663 Development  kit ), the entire firmware image can be  downloaded into I2C based EEPROM. After reset the image will boot  from the EEPROM.

ii. Download to on-chip RAM: The image can be downloaded directly to RAM using load_ram utility which is a PC based bash shell script. Please refer to these scripts in CY4640 RDK firmware example folders (msc, scsi).

Since CY7C67300 has an internal CY16 RISC based processor with BIOS, it requires less CPU bandwidth because it takes a list of transfer descriptors and operates on them on a frame basis. Since SL811HS does not have an internal processor, it will require more external CPU bandwidth because it must deal with individual packets. SL811HS has 8-bit interface + cntl lines while CY7C67300 has 16-bit HPI, SPI or HSS interface.

Besides this, there are certain OTG protocols that the SL811HS does not support. As for example, the SRP and HNP protocols are among the few protocols that are not supported by this product.

1. The code can actually be compiled using a standard compiler to run on a windows based system. This of course will use the x86 processor with a larger available memory and so typical debugger functions can be used.
2. If the code is pared down to just the necessary code for debugging and just the section of code that you need to debug is actually built with the debug symbols, you may be able to get the code to run in the part with the debugger.
3. The CY4640 includes hardware tracing so the user can connect a logic analyzer to the memory bus and trace various functions.
4. The CY4640 utilizes the serial terminal for exercising the RDK. This serial terminal connection also provides a good way to display useful information and can be used as a debug tool.

Thes options are covered in detail in a document found in the $HOME/Docs/CY4640 directory and is called CY4640 Debugging Options.

The CY4640 MSC driver will match using VID/PID and Class/Protocol codes. The bInterfaceSubclass in the Interface Descriptor is typically 0x06 for mass storage HDDs, which is the SCSI Tranarent Command Block set. If other bInterfaceSubclasses are required then the user will be required to make the modifications to accomodate any necessary changes. This may include changing the command structures in the scsi.h file.

The better solution is to use the CY7C67300 (EZ-Host). The CY7C67300 has an external memory bus and so the available memory can be expanded and thus more functionality can be place in the EZ-Host. This is exactly what the CY4640 does and expands the available memory from aproximately 15KB in the EZ-OTG to a combind value of up to about 54KB without use of paging.

Another option to consider is using the EZ-OTG part in co-processor mode instead of in stand-alone mode. When doing this the RTOS that is running in the external processor?will not have these same constraints and they typically have a USB stack with a USB Mass Storage Class driver.

The GPIO25 interrupt functions the same regardless of standalone or coprocessor mode. GPIO24 is used for the HPI interrupt or in HPI mode or used as IOReady in IDE mode. If either HPI or IDE is enabled, then GPIO24 is no longer a general purpose interrupt.

The GPIO25 interrupt functions the same regardless of standalone or coprocessor mode. GPIO24 is used for the HPI interrupt or in HPI mode or used as IOReady in IDE mode. If either HPI or IDE is enabled, then GPIO24 is no longer a general purpose interrupt.

CY3663 - EZ-OTG / EZ-Host Development Kit

void sie1_install_descriptor(void)

{

/* Set OTG-Host device descriptor pointer to point at our device descriptor. */

WRITE_REGISTER( SUSB1_DEV_DESC_VEC, &device_descriptor );

/* Set OTG-Host config descriptor pointer. */

WRITE_REGISTER( SUSB1_CONFIG_DESC_VEC, &sie1_descriptors.config_descriptor );

#if NUM_STRING_DESCRIPTORS > 0

/* If we have some string descriptors, set string descriptor pointer. */

   WRITE_REGISTER( SUSB1_STRING_DESC_VEC, &sie1_string_descriptor );

#endif

/* Put the device on the bus. */

}

Here you see that we write the descriptor pointers to their software interrupt vectors, which are mapped in the cy7C67200_300.h file found in the common directory. For more information regarding interrupt vectors refer to the BIOS User manual. Once the SIE is enabled the BIOS should take care of all of this including sending the correct status.

Related Links:

Cypress CY3663 OTG-Host Development Kit

HSS_TxD : OUT from EZ-Host/OTG;

HSS_RxD : IN to EZ-Host/OTG;

HSS_CTS : IN to EZ-Host/OTG;

HSS_RTS : from EZ-Host/OTG;



UART_TxD : OUT from EZ-Host/OTG;

UART_RxD : IN to EZ-Host/OTG;



Keywords: EZ-Host, CY7C67300, EZ-OTG, CY7C67200, HSS, UART, directions


ID: BGE03082107

As an example, you can run design example 4 (de4) using the GDB debugger as follows:
1. FWX_SERIAL_EEPROM in fwxcfg.h must be undefined. In order to use the debugger, this must not be defined. This is described in the Frameworks Reference Guide.
2. The de4.ld file must be modified to change the org point to 0x1000. This will allow room for the GDB stub to be loaded into memory.
Also, you will have to run the debug session through the serial port instead of the USB port because design example 4 takes over control from the BIOS for the USB port on SIE2.

 

You can decrease this EOT time and increase the throughput by changing:

1. The MAX_FRAME_BW define in the cy7c67200_300_hcd_simple.c file.
This number defaults to 4096 (~bits per frame). You'll want to increase this, possibly upto 6-7K.

2. The DEFAULT_EOT define in the cy7c67200_300_hcd.c file.
This number defaults to 4800 (40% of frame). You'll want to decrease this, probably no lower then 1200 (10% of frame).