I cannot get the GPIOs working on my CY7C65211. What I have is:
-a working device configured as I2C + PC side software
-GPIO 11 appearing as "unused" in the Configuration Tool
-GPIO 11 alternatively configured as Driven 0/Driven1/Tristate - no change
-Briefly tried other GPIO ports too
My code line:
cyret = CySetGpioValue(cyhandle, 11, 1);
always returns CY_ERROR_REQUEST_FAILED. 'cyhandle' is valid, e.g.
CySetI2Config() accepts it.
Is there some GPIO-specific initialisation I need to run?
Should GPIOs be usable when the device is in I2C mode?
Is there any example source code that drive GPIO?
I have thus far only tested on Linux with the latest CyUSB SDK (Feb. 6, 2016), Ubuntu 16.04.
Solved! Go to Solution.
I found an GPIO example hidden in the Windows SDK package.
I tried to compile this, it wouldn't - turns out the example expects
"CY_DEVICE_SERIAL_BLOCK deviceBlock;" to be part of "CY_DEVICE_INFO",
which is restricted with "#ifdef WIN32".
Porting away these compile-time issues, the program still fails in CyOpen().
So my remaining questions now are:
-Should GPIOs work with a device configured as I2C?
-Should GPIOs work with non-windows hosts?
p.s. I'd post my ported gpio.cpp, but Cypress' original example is "CONFIDENTIAL"
Doh - I forgot "CyGetDeviceInfoVidPid()" is broken on Linux.
Now working around that, I'm seeing the same failure to write GPIOs with the (now heavily modified) Cypress example code
as with my own.
I even tried swapping my device for the CYUSB234 devkit, in UART mode. No change.
So it seems GPIOs can be toggled only via Windows hosts. I hope Cypress can confirm (or better yet, disprove) this.
Hello Kalle Raiskila,
- The GPIOs would work even if the device is configured for I2C. You could test this with the example application code that comes with the USB Serial SDK http://www.cypress.com/documentation/software-and-drivers/usb-serial-software-development-kit. Also, ensure that the GPIOs are configured in the USB-Serial Configuration Utility before using them in the application.
- The API library can be used with Windows/Linux/Mac-OS.
thank you for confirming the I2C & platform issue. So if it should work, I have an error somewhere.
I double checked - the GPIO I tried with was configured "Tristate" in the Configuration Utility's 'GPIO' section.
Now would you have examples that are known to work with GPIO on Linux? I could not find any GPIO examples in the Linux or Mac SDKs. The one in the Windows SDK didn't even compile out of the box. I'm afraid I messed it up when getting it running, since it don't work now.
The error I'm getting from libusb is a LIBUSB_ERROR_PIPE, form the libusb_control_transfer() in CySetGpioValue(),
which libusb documents as "the control request was not supported by the device"
Any ideas on what might be causing this?
I managed to get the 'gpio' example compiled under Windows. It fails similarly 'CySetGpioValue()' returns CY_ERROR_REQUEST_FAILED. The example code is unmodified, GPIO_10 is configured as 'Tristsate', device is a CYUSBS234 DVK Board.
I had to do something Visual Studio named "Retarget solution", to Windows SDK 10. Does this break the example code?
Any suggestions welcome.
Hello Kalle Raiskila,
- Please configure the GPIO to HIGH/LOW in the USB-Serial Configuration Utility and check with the same host application.
- Retargeting to Windows SDK 10 does not harm the code.
thanks, this got the example working, both on Linux and Windows.
Seems I never tried with Drive 1 / Drive 0 with the CYUSBS234, and the Cypress example, and I have some bug in my own software/board.
The datasheet does has a description of "DRIVE 1 Output static 1", which confused me.
Seems it is not 'static' but more of a 'reset value'? But why doesn't Tristating the output work?
Or does that mean it is high-Z-only?
EDIT: seems the API can only drive the GPIO to high or low, not to high-Z. At least not without flashing a new configuration set, which then seem to require a power cycle. So what I was trying to achieve is impossible with this chip.