Hi everyone,

I'm debugging a camera firmware which is developped based on this: https://www.cypress.com/documentation/application-notes/an75779-how-implement-image-sensor-interface-using-ez-usb-fx3-usb

The cypress camera works fine except that seldomly during video streaming the camera somehow stops and when I check usb desctiption with lsusb -v, I saw that its descriptor is corrupted. And in dmesg I saw:

[ 8720.318320] usb 1-1.4: new high-speed USB device number 28 using xhci-hcd
[ 8720.419525] usb 1-1.4: config 1 contains an unexpected descriptor of type 0x1, skipping
[ 8720.419534] usb 1-1.4: config 1 has an invalid descriptor of length 1, skipping remainder of the config
[ 8720.419540] usb 1-1.4: config 1 has 1 interface, different from the descriptor's value: 2
[ 8720.419548] usb 1-1.4: config 1 interface 0 altsetting 0 has 0 endpoint descriptors, different from the interface descriptor's value: 1
[ 8720.420738] usb 1-1.4: config 1 has an invalid descriptor of length 1, skipping remainder of the config
[ 8720.420747] usb 1-1.4: config 1 has 0 interfaces, different from the descriptor's value: 2
[ 8720.423854] uvcvideo: Found UVC 1.00 device _v1.4.0 (04b4:00f8)
[ 8720.423873] uvcvideo: No valid video chain found.
[ 8720.423919] usb 1-1.4: Unsupported device

 Is there anyone has the same problem ?

Thank you very much

Hi everyone,

I want to configure the DS-1 port of CY611 EZ-USB HX3PD EVK to supply 12V. But when I try to configure  using EZ-USB HX3PD configuration Utility - PD Controller- Port 1, it shows me error - Atleast one 5V PDO should be enabled in Source PDO. But if add another source PDO of 5V, it does not save the configuration.

Can anyone help please ?

Thanks

Sugreev

Hi,

Could you please help me with Schematic and firmware design support to drive Segment LEDs using the PSoC 5LP chip?
We have to drive a seven-digit seven segment display with various segment current from 16-bit serial input.

Regards,

Mari 

Hello:

I'm trying to flash a ARS6501 device (PSoC CY8c4147azi-s445 inside) using CMSIS-DAP and PSoC Programmer 3.29.0

The SWD adapter is detected by the programmer, however, the device is never acquired. I tried multiple times, with different CMSIS-DAP versions (v1, v1.1 and v2.0) but none worked! I always get "FAILED! PSoC device is not acquired! Check connection of the chip to the programmer..." error.

I checked all connections many times, and also probing the signals with the scope and I can see RST, SWCLK and SWDIO toggling trying to get response from device, but no luck so far... Only thing I notice is RST pulse is only 50ns, which seems to be small compared to what the PSoC Programming Specification states; however, I don't see how to actually change this as it's supposed to be handle by the programmer software.

Also tried two devices with same behavior so I don't think it's the device.

So my question is; it's really possible to acquire the device using CMSIS-DAP?

Thanks in advance;

Gus

We have implemented a power switch architecture using the CYUSB3304, that is similar to figure 17 of the AN94150 App Note ("Designing a SuperSpeed Hub..."), without the recommended Q1 MOSFET.

In our design we have 4 USB ports and each port has its own USB power switch.  The 4 power switches are enabled by a common PWR-EN signal from the CYUSB3304 and the over-current flags out of the power switches are tied together as a common flag back to the CYUSB3304.  The 4 power switches receive 5V from a local 5V regulator. The power switches are set to trip at 500mA.

When we create an overcurrent condition, by putting a programmable load on the 5V pin on the USB port, the power switch asserts the OVRCURR pin on the CYUSB3304. In response, the CYUSB3304 switches off the power by de-asserting PWR_EN, which in turn makes the power switch de-assert OVRCURR.

Next, we assume that the CYUSB3304 should periodically check if the overcurrent condition is resolved, by re-asserting PWR_EN and monitoring OVRCURR.

HOWEVER we find that this re-try process takes a very long time and is indeterminate:

When the overcurrent condition is removed, the power enable pin takes a variable amount of time to return to the high state. This time was found to be anywhere between 2 seconds (2 to 5 seconds a few times) and 4.25 minutes (once). Most attempts took 10 to 30 seconds but quite a few were over 1 minute.

In practice, this means that the USB on our product will be disabled for 10-30 seconds after an overcurrent condition - up to 4 minutes.

Is this normal behaviour for the CYUSB3304? If not, what can we do to address this?  We would also like a description of the over-current recovery process; the datasheet does not mention it.

Hi,

I am working with a CYW4343W and WICED Version: Wiced_006.004.000.0061

My Central application is behving as expected for most of the time, scanning for and connecting to a BLE Server, performing Service and Characteristic discovery, writing to the Server's CCCD, pairing and bonding etc. However, if I leave it to run for a few hours it will intermittently receive the BLE management callback event BTM_ENABLED_EVT with a value of WICED_TIMEOUT for p_event_data->enabled.status.

I have found that ignoring these WICED_TIMEOUT events ultimately results in one the of subsequent calles to a WICED BLE API function such as wiced_bt_gatt_send_discover() etc not returning, after which my application will hang awaiting the API call to return.

My short-term solution is to reset my device whenever the application receives BTM_ENABLED_EVT with a value of WICED_TIMEOUT. However, I would like to know what is the recommended procedure for handling such errors, please?

Also, what are the most likely causes of the BTM_ENABLED_EVT with a value of WICED_TIMEOUT, please?

Regards,

R

Hello,

I had another question regarding another post that I inquired about not long ago (link below):

https://community.cypress.com/t5/USB-Hosts-Hubs-Transceivers/HX3-Downstream-USB-3-0-to-Type-C-Receptacle/td-p/34438

For my application, I wanted to connect a USB Type-C receptacle to the CCG3PA for PD charging capability as well one of the downstream ports of the HX3 for USB 2.0/3.0 data. I originally wanted to retain legacy charging by connecting the Dp and Dm lines to both the CCG3PA as well as the HX3 since the CCG3PA has more charging profile capabilities. To reduce complexity, I decided to simply connect the Dp and Dm lines to the HX3 because BC1.2 and Apple Charging would suffice for the application. With this configuration, how would you recommend the downstream charging to be controlled considering that PD and legacy charging would be controlled by different devices? 

Could I do any of the following:

• Supply legacy charging through a USB charging switch and supply PD charging through the CCG3PA and tie the USB Type-C receptacle's VBUS to both?
• Connect the HX3's DS1_PWREN and DS1_OVRCURR to the CCG3PA gpios (with modified firmware) so that the CCG3PA can act as the charging switch for legacy charging?
• If neither of these would work, what is the best way to retain both USB2.0 data as well as legacy charging functionality with the configuration described above?

Thanks in advance!

Chris

I'm looking to interface external memory with one of the PSoC 6 chips. Our application has large storage requirements (to the tune of around 2-4 gigabytes), so SPI NAND is off the table. Since our use case needs bluetooth and possibly USB, we were looking at the PSoC 63 line, but these chips don't seem to support e.MMC memory, which has raised a few questions?

Is there a (relatively) easy way to interface with raw unmanaged NAND using the PSOC 6 line, or to use e.MMC with PSoC 63? Alternatively, is anyone familiar with any chips that could serve as an intermediary SPI Controller to go between a raw NAND chip and the PSoC MCU, or any other way to work around this? 

The PSoC 62 chips seem to have support for SDHC communication, but to use bluetooth and USB I believe we would need one of the CY8C624A/8 chips with two SDHC interfaces. 

Would appreciate any insight on this, as we'll otherwise need to move away from the PSoC chips and start looking at alternatives.