USB low-full-high speed peripherals Forum Discussions
I am using the CyUSB.dll (v3.4.6) in C# and it works great when my build target is x86 but if it's x64 I get an OverflowException when I call USBDeviceList(). It seems like someone else had this same post at https://community.cypress.com/thread/25307 but I don't have access to that thread.
Thanks
Show Lesshello. I used CYUSB2014-BZXC chip for getting data from GPIF.
CYUSB2014-BZXC Booting mode is usb boot. and I did upgrade firmware with RAM mode
The configuration of my board is as follows.
CYUSB2014-BZXC is conneted with ARM CPU by USB 2.0 Interface.
data line is conneted with CYUSB2014-BZXC by GPIF ( use 0-7 data line. and data valid line is connected with GPIO18. and CLK line is connected with GPIO16 )
At first, the CYUSB2014-BZXC chip was recognized normally in the kernel.
I used the GpifToUsb example source to create the firmware, apply it to the board, and test it. At some point, the chip is not recognized.
After that, it is not recognized even if hardware reset is executed.
As far as I know, I know that hardware reset will boot with default firmware.
When the kernel is booted with hardware reset, the CYUSB2014-BZXC is not visible on the usb bus. Running lsusb or running 01_getdesc does not show CYUSB2014-BZXC on the usb bus.
I want to know how to fix CYUSB2014-BZXC. And I want to know why this is happening.
Show LessHi
whenever i used to program the eeprom (24lc128) on development kit FX2LP(CY3684) ,following error occur "EEPROM NOT ENABLED" Is there any way to load / program the new eeprom according to development kit FX2LP(CY3684)? Below is the link of website from where i bought the new eeprom for development kit FX2LP(CY3684).
https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=24lc128-i
Show LessHi all,
I'm using a CY7C68013a hi-speed USB interface chip.
According to the docs there are thee modes: Slave FIFO, GPIF Master, and Ports I/O
In Slave FIFO mode, the CTL/FLAG pins operate as FLAGA...FLAGC
In GPIF Mode, the pins operate as CTL0...CTL2 and are controlled by GPIFIDLECTL ( except when doing a transaction )
... My question is what these three pins do when in Ports I/O mode? - are they tri-state or under control of GPIFIDLECTL,... ?
Also - do writes to GPIFIDLECTL have immediate effect (on these pins)when in GPIF idle mode or is that sampled when entering idle mode?
- Thanks!
Show LessHi,
Here and here and here and here and here , information can be found on the Utilization of the Unused GPIF Control Lines in Port Mode.
The first one is the most informative, the last one might benefit from an update (it says that it would be better to use other GPIOS, but the question was rather if it can be done, not if there were more practical ways).
What I get from those articles ist, that it is indeed possible to utilize unused GPIF Control Lines as GPIO lines in GPIF Mode, but that one has to care that these lines will not be utilized by the GPIF engine or otherwise data corruption can occur.
The information that I am missing, is if these control lines can be utilized also in the port mode. Is their state in port mode the same as in GPIF mode in the Idle state? Or are they in some other state like high impedance, and are only active if GPIF mode is active?
Added by edit:
If I change the according GPIFIDLECTL register values in order to change the control signals (from low to high or vice versa), I assume these changes have direct effect on the pins if GPIF mode is active and the state machine is in the Idle state.
What if I update these register values when the GPIF is in any other state? Does my update have a direct effect or does the register update only take effect once the state machine arrives at the Idle state again?
Assuming that the control lines are also active in Port mode: What if the Port mode is active and I update the GPIFIDLECTL register? Does my update have a direct effect or does the register update only take effect once I switch to GPIF mode(at least temporarily)?
Also regarding any output: I assume in suspend or idle mode (power management) all the active outputs stay active and keep their actual logic output state, right? And any current that is drawn out of a high output has to be added to the suspend current?
Thanks in advance.
Show LessI need to interface 8 bit cmos camera to USB HS 2.0 controller (Cy7C68013A 56-pin). The 16 line pin outs of the camera is mentioned (also attached).
Eight data lines (D0-D7)
Three control and synchronisation lines (PCLK,VSYNC,HSYNC)
Two I2C lines (SDA,SCL)
One LED control line
GND
+3.3V
The cmos camera has a resolution of 640x480 and gives the frame rate of 8 fps.
The data from the data lines (D0-D7) comes in sync with the PCLK (pixel clock) at a rate of 320ns. The cmos image sensor has a clock of its own which controls the PCLK signal.
I am now looking into the hardware interface of the cmos camera sensor with the cypress microcontroller (CY7C68013A 56-pin) and these are my interpretations on the hardware connections.
The cmos camera data lines (D0-D7) needs to be connected to PB0 to PB7 as the slave FIFO interface mode.
The I2C iterface on CY7C68013A is used to configure the cmos camera registers.
Data is valid when VSYNC, HSYNC, PCLK all are high. Where can I interface the PCLK, VSYNC and HSYNC signals ?
Do they need to be interfaced to read/write strobes (SLRD/SLWR) or the interrupt lines (INT0/INT1) on the micro controller.
Thank You
Show LessHi,
I'm facing a problem when install USB-Serial SDK to Windows 10 PC.
Below are error message. Even I've installed Microsoft VC++ 2008 Redistributable and try again, but it does not solve the problem.
Please give me advise.
Regards,
Show Less
Can anyone recommend a HID testing tool that runs under Windows 7 ?
Hello,
I'm trying to use a PSoC as a USB HID Single Touch Device. (PSoC 4200L with USB interface)
I used the following Descriptor that works as a mouse with absolute coordinates:
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x02, // USAGE (Mouse)
0xa1, 0x01, // COLLECTION (Application)
0x09, 0x01, // USAGE (Pointer)
0xa1, 0x00, // COLLECTION (Physical)
0x05, 0x09, // USAGE_PAGE (Button)
0x19, 0x01, // USAGE_MINIMUM (Button 1)
0x29, 0x03, // USAGE_MAXIMUM (Button 3)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
0x95, 0x03, // REPORT_COUNT (3)
0x75, 0x01, // REPORT_SIZE (1)
0x81, 0x02, // INPUT (Data,Var,Abs)
0x95, 0x01, // REPORT_COUNT (1)
0x75, 0x05, // REPORT_SIZE (5)
0x81, 0x03, // INPUT (Cnst,Var,Abs)
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
0x35, 0x00, // PHYSICAL_MINIMUM (0)
0x46, 0x9d, 0x0b, // PHYSICAL_MAXIMUM (2973)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0x9d, 0x0b, // LOGICAL_MAXIMUM (2973)
0x65, 0x11, // UNIT (SI Lin:Distance)
0x55, 0x0e, // UNIT_EXPONENT (-2)
0x75, 0x10, // REPORT_SIZE (16)
0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x02, // INPUT (Data,Var,Abs)
0xc0, // END_COLLECTION
0xc0 // END_COLLECTION
It works fine with Windows 7 and Linux, but the problem is that my windows embedded CE 6.0 device interprets the coordinates as relative values.
Does somebody has experience with single touch devices that works even with windows embedded and could help me with that problem?
Or does somebody know any example project that I overlooked?
Best regards, Markus
Show LessDear support,
During the communication between the FX3 and the HOST (windows computer), I get an extra response packet from the FX3 (that is malformed by the way) to the GET DESCRIPTOR request configuration sends by the host.
Like you can see in the picture, the event n°527 GET DESCRIPTOR request configuration gets its response, with no errors, from the FX3 with the event n°528 GET DESCRIPTOR response configuration. The problem is that the event n°530 also responds to the event n°527 and is malformed.
I need your help to know why there would be a second response to a request that is already treated. Because of that, I have a SET CONFIGURATION done that recreate all my threads.
Thank you for Help,
Cedric
edit : all request on descriptor are handled by the functions of Cypress, not by my code.
Ce message a été modifié par : Cédric JAYET-GRIFFON
Show Less