Hi Everyone,

I am designing a PCB using CY6611- EZ-USB HX3PD Evaluation Board. I was working on the Schematic of my PCB. I was not able to find the AIC6156 power switch by Analog Integrations Corporation used for non-PD ports (DS2 to DS7). 

Can you please help with the datasheet/ information/alternative of the same.

Thanks

Sugreev

We have been using CyUSB.DLL with our VC# program that interfaces with our product using a PSoC5.  We are using Generic HID.  Now the Cyber Cops are telling us we need a signed DLL.  Considering CyUSB is so old, is there another option that is already signed?

Mike.

Hi,

I am having an issue with motor driver communication, and I would like to ask if my SPI code is correct.  I am only getting 0xFFFF for any register that I am trying to read, and I know that that is not correct for startup of the registers.

The guts of the code is here:

uint16 DRV8323_Read(uint8 addr)
{
    // Dummy byte needed to clock in read data
    uint16 dummy = 0x00;
    
    // Write read command and address
    // Read bit is MSB, addr takes up next 4
    uint16 cmd = ((SPI_READ << 15) | (addr << 11));
    SPI_DRV_SpiUartWriteTxData(cmd); 
    // Write Dummy
    SPI_DRV_SpiUartWriteTxData(dummy);               

    // Wait for data to be received - is size consisting of 16 or 8 bit elements?
    while (SPI_DRV_SpiUartGetRxBufferSize() < 2) {}    
    
    // Read both data bytes
    // dummy
    data1 = SPI_DRV_SpiUartReadRxData();  
    // return data
    data2 = SPI_DRV_SpiUartReadRxData();  
    
    SPI_DRV_SpiUartClearRxBuffer();
    
    // Return register data
    return (data2);
}

Attached is the full test project.

Datasheet for the motor driver is here:  DRV8323 

Thank you in advance for any help that can be offered.

Regards,

Tom

Hello!

We have been using the CP62167EV30LL-45BVXI memory on our modules since 2014.

We were affected by the AN66311 in 2014
"TIMING RECOMMENDATIONS FOR BYTE ENABLES AND CHIP ENABLES IN MOBL (R) SRAMS - AN66311"

After this bug was fixed by Cypress and we received new CP62167EV30 components, the error on our modules disappeared.

Until now in 2021.

Memory errors are now increasingly occurring on our assemblies during the final inspection, failure rate approx. 50%. After asking us, we were able to determine that Cypress has changed this SRAM from 90nm technology to 65nm technology.

Hello!

I looked at the data sheet and compared it with the old one and couldn't see any significant changes. An analysis of the memory accesses, timing, etc. on the defective assemblies has not been successful either.

If defective modules from production are equipped with the previous 90nm CP62167EV30LL-45BVXI, then they will function properly again.

Could it be that by changing the technology from 90nm to 65nm, the old bug from AN66311 was redesigned.

I am grateful for a quick answer.

greeting
Max power

We have two variables , 1 is being updated by one Core (FBL-CM4) and are being used by other core (FBL-CM0).

2nd variable is common to both FBL CM4 and CM0.

But these variables should not be updated by other cores such as APPL CM4 and APPL CM0 ( for 1st variable FBL CM0 too ).

Could you please provide a sample code to protect these 2 variables using IPC. 

1. volatile uint32 TempState1;

2. static TempStatetype TempState2;

typedef struct

{

       Statevalue; //Holds enum value        

       DataFeild; //Holds uint32 value

}TempStatetype

We are using a third-party configurable HID board which uses the CY7C64215. I would like to integrate this function onto our own board, which will need support for at least 5 years. Is the CY7C64215 still a good choice for this, or should we use a newer IC?

Our application is only 8 buttons and 2 analog inputs which need to be used as USB HID devices.

Thanks!

Hello all,

I am currently using a psoc CY8C6347BZI-BLD53 to do some very high speed SPI transfers at 25MHz and have come across some interesting behavior of the SPI FIFO. 

Initially I was using the Cy_SCB_SPI_Write() to fill the FIFO to 64 with uint16_t values that is triggered when the FIFO reached a value of 8. Upon further investigation with an oscilloscope there was some delay between transfers  (~570ns) and a larger delay (~972ns) between them when writing to the FIFO during an interrupt using that api.

The delay between each message becomes one clock cycle consistently when using Cy_SCB_WriteTxFifo() even while writing to the FIFO which solves my timing critical problem. However, I now begin to receive the interrupt after ~30 values being transferred, which means the FIFO isn't being fully filled to the value of 64 (i'm guessing ~38) . I found that if I add a delay of ~20 cycles after each call of Cy_SCB_WriteTxFifo() the right number of data (54) can be seen transferring on the oscilloscope before the next interrupt occurs.

I am reaching out for some help with trying to eliminate the added delay cycles after each Cy_SCB_WriteTxFifo, or at least to understand the root cause of why it work when they're there. I have looked into the TRM for the architecture, but they do not go into detail about FIFO operation. I don't have a usb right now so I can't post images from my oscilloscope but if you need them to understand I should have one by this Monday.

Your help is greatly appreciated!

Hello, my lab has an older design for a digitizer which implements the CY7C65631 USB 2.0 Hub. Currently the Vcc, Self Power, /Reset and OVR pins are connected to the output of a 3.3V regulator. Unfortunately I need to increase the output of this regulator to 3.5V for reasons that have nothing to do with the Cypress CY7C65631 part. I have reviewed the data sheet for the part and see that the max supply voltage for operating conditions is 3.45V and the absolute maximum rating is 4.0V. Does operating at just outside the 3.45V range reduce the lifespan of the part? Since the applied voltage would still be < 4.0V I think we should be safe from risking an over voltage failure on the part? I am just trying to get a sense of the risk involved with operating the CY7C65631 part at 3.5V instead of 3.3V.

Thank you

-Sean

I'm hoping somebody could please explain the pros and cons of running the PSOC 6 BLE stack on CM0 instead of CM4 like all sample code I've seen demonstrates. First of all, is running it on CM0 even possible? It seems to me that the BLE stack is a low load software module that should work equally well on either core. I would love it if somebody could point me to any appropriate (and current!) app notes and/or example projects.

I'm providing BLE programming expertise to a customer. I have only a few months of experience using the PSOC 6 BLE module so the core selection tradeoff is new to me.

Thanks - JJS

When I start EZ-PD Analyzer Utility it says "EZ-PD Analyzer is not connected", but when I check Windows Control panel it's there: