USB low-full-high speed peripherals Forum Discussions
API for the GPIO (CyGetGpioValue()/CySetGpioValue()) does not allow us to change the direction/drive of the GPIO pins on CY7C65211. In our system we may have a number of this USB-I2C bridge device and we want to be able to configure the GPIO direction/configuration individually on each of these bridge devices at least at system initialization. Is it possible achieve this with CY7C65211?
I see that you recommend to use the configuration utility to do so; in other posts. Do you have a Linux utility to do so? Even if there is one, it will be difficult to call it form our application. Can you please add APIs for this purpose?
Show LessHi,
From this discussion FLAGC set to not empty after TD_Init , using the same firmware.
I have a problem with this firmware, reading from EP6 (from external master), greater than 1024 cause the last buffer data to be zero.
Let's say, I need 1050 number of data to read, the first 1024 is okay, but the next data is zero.
Please be inform that external master sends PKTEND.
Thank you for your support.
Best regards,
Livie
Show Less
Hi,
I tried to build the Streamer example application from the USB Suite 3.4.7 with VS 2017 Community, but I get a lot of errors.
It does not recognize the System::Windows namespaces, expects or misses tons of declarations and so on.
Can anyone point me to a walk through guide for building these examples with VS 2017 Community?
I don't know if they are buildable with any other VS version, because I only have that one.
Thanks in advance
Show LessI only use CY7C63813,didn't have SPI chip.Move the track ball.Light pulses into the CY7C63813 by IO pin.
The direction of the motion is calculated by different pulses.The difficult is how to calculate the distance???
Show LessHi,
I want to use Slave FIFO Mode.
In this setup, I want to utilize all End Point (2,4,6,8).
EP2 & EP4 is AUTOOUT=1 while EP6 & EP8 is AUTOIN=0.
I set PINFLAGSAB = 0, and PINFLAGSCD = 0, so that all FIFO flags are indexed as pointed by FIFOADR[1:0]
My problem is after initialization of the firmware.
FLAGB is set to LOW
FLAGC is set to HIGH, therefore I cannot write to EP2, if selected by FIFOADR[1:0]. Why?
and at Vendor Command returning EP2468STAT value is 0x5A.
that is: EP8E,EP6E & EP4F, EP2F.
Why EP4F and EP2F at initialization?
(I attached my code)
Thank you for your help.
Show LessSo I am trying to get my host application to work with the new cyusb3.sys. As mentioned in the PDF, some of the IOCTL definitions have changed. I am not a coder and am just the tech trying to get it to work. I have all the source code etc...
I could use some help with changing the code. Here is the IOCTL code from the host application.
' ************************************
' IOCTL Definitions
' ************************************
' Set the base of the IOCTL control codes
Private Const Ezusb_IOCTL_INDEX = &H800
' (DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method)
' note: DeviceType for each control code is FILE_DEVICE_UNKNOWN
' FILE_DEVICE_UNKNOWN * 2^16 = &H220000
' 'Access' = FILE_ANY_ACCESS = 0
Public Const IOCTL_Ezusb_GET_PIPE_INFO = &H220000 + METHOD_BUFFERED + (Ezusb_IOCTL_INDEX + 0) * 4
Public Const IOCTL_Ezusb_GET_DEVICE_DESCRIPTOR = &H220000 + METHOD_BUFFERED + (Ezusb_IOCTL_INDEX + 1) * 4
Public Const IOCTL_EZUSB_BULK_READ = &H220000 + METHOD_OUT_DIRECT + (Ezusb_IOCTL_INDEX + 19) * 4
Public Const IOCTL_EZUSB_BULK_WRITE = &H220000 + METHOD_IN_DIRECT + (Ezusb_IOCTL_INDEX + 20) * 4
Public Const IOCTL_Ezusb_RESETPIPE = &H220000 + METHOD_IN_DIRECT + (Ezusb_IOCTL_INDEX + 13) * 4
Public Const IOCTL_Ezusb_ABORTPIPE = &H220000 + METHOD_IN_DIRECT + (Ezusb_IOCTL_INDEX + 15) * 4
Public Const IOCTL_Ezusb_SETINTERFACE = &H220000 + METHOD_BUFFERED + (Ezusb_IOCTL_INDEX + 16) * 4
'---- Usage
'result = DeviceIoControl(hUSB, IOCTL_Ezusb_RESETPIPE, PipeNumber, 0, 0, 0, lBytesReturned, 0)
'result = DeviceIoControl(hUSB, IOCTL_Ezusb_ABORTPIPE, PipeNumber, 0, 0, 0, lBytesReturned, 0)
'result = DeviceIoControl(hUSB, IOCTL_Ezusb_SETINTERFACE, tSetInterfaceIn, Len(tSetInterfaceIn), 0, 0, lBytesReturned, 0)
'#define IOCTL_Ezusb_RESETPIPE CTL_CODE(FILE_DEVICE_UNKNOWN, \
' Ezusb_IOCTL_INDEX+13,\
' METHOD_IN_DIRECT, \
' FILE_ANY_ACCESS)
'
'#define IOCTL_Ezusb_ABORTPIPE CTL_CODE(FILE_DEVICE_UNKNOWN, \
' Ezusb_IOCTL_INDEX+15,\
' METHOD_IN_DIRECT, \
' FILE_ANY_ACCESS)
'
'#define IOCTL_Ezusb_SETINTERFACE CTL_CODE(FILE_DEVICE_UNKNOWN, \
' Ezusb_IOCTL_INDEX+16,\
' METHOD_BUFFERED, \
' FILE_ANY_ACCESS)
Show LessWhen configured as USB-I2C bridge, there are 3 endpoints on CY7C65211. Please see below. Is it possible to get rid of Interrupt end-point? We are connecting a number of these devices to an xhci controller and we want to keep the number of endpoints to a minimum, since we don't want to run into resource constraints in the controller.
root@lsys:~# lsusb | grep -i cypress
Bus 001 Device 005: ID 04b4:000a Cypress Semiconductor Corp.
root@ls1043ardb:~#
root@ls1043ardb:~# lsusb -v -s 1:5
Bus 001 Device 005: ID 04b4:000a Cypress Semiconductor Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04b4 Cypress Semiconductor Corp.
idProduct 0x000a
bcdDevice 0.00
iManufacturer 1 Cypress Semiconductor
iProduct 2 USB-I2C (Dual Channel)
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 48
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 5
bInterfaceProtocol 0
iInterface 0
Device Status: 0x0000
(Bus Powered)
root@sys:~#
Show Lesshi everyone ,
actually i want make control centre as the console application .i got struck at selecting endpoints in device tree view ,can any one suggest me the best way to do without selecting endpoints how to read data from usb2.0 .if any one faced this situation please let me know how you people solved this .
best regard
veerendra
Show LessIn our recent mass production, we found that there're minor part (~2%) of the device (using CY7C68013A) doesn't
read firmware from Eeprom on certain conditions. That only happens if user plugs off the USB cable (which also provides
power to device) from the device and quickly plug it back on (e.g. within 5 seconds)...Note that we observed
the main powers (including 5V, 3.3V and others), all of them are down to GND in 1 second (When plug off), and the on board
voltage monitor will reset the MCU (CY7C68013A) when the 3.3V Vcc reaches ~2.8V (When power on)...When such issue occurs,
the Powers, Reset, Clock to CY7C68013 are all good, but we didn't observe any the I2C pulses on the I2C bus (on normal
booting, there're many such I2C activities when device is plugged on and the MCU reads firmware from Eeprom).
If we wait for longer time (after plug off), e.g. 20 seconds, such booting fail rate is lower...the issue was gone if waiting
for 30+ seconds (and plug back).
Note:
1). Such issue only show up on minor part of the devices (~2%).
2). For a problematic device, it has rate (e.g. 50%) to show the issue even we do a quick plug off/on.
3). For a problematic device, if we wait longer after plug off (and then plug it on), the rate is much lower.
I understood that this might be the PCBA hardware related issue (e.g. soldering issue), but my question is what might make
the CY7C68013A is stuck in the boot loader and can't read firmware from external Eeprom.
Thanks!
Show LessHi,
We would like to confirm about flash retention of CY7C65213/CY7C65213A (USB-UART Bridge).
Specification of flash is described on page 11 of datasheet.
10K program/erase cycles : 10 years (min)
From the above, We understand that it is 10 years by 10K program/erase cycles.
Do you have information on retention period when programed once?
Regards,
Masashi
Show Less