All Forums

I want to use STM32 to program CY27410 through i2c. According to another topic, an NDA is needed. How do I receive an NDA from you? My email is zhz13456@163.com.

Thanks in advance.

I'm a software engineer with RTP Corp.  We are using the CY7C68001 EZ-USB SX2 High Speed USB Interface Device.  We have an embedded software design used for process control and have written a simple embedded USB driver.  Our devices are limited to one USB port with one USB High Speed device (the CY7C68000).  The USB device is on-board with the CPU chip-set (Intel SCH US15W)   We transfer data using four endpoints.  Two of the endpoints transfer about 1072 bytes of output data, and 245 bytes of input data continually at a 1 millisecond rate. The other two endpoints transfer 512 bytes or less of output or input data randomly to communicate with flash memory.

The USB host controller is an Intel EHCI device built into the chip-set.  The software mostly polls the EHCI, and the only interrupt is the Interrupt On Completion of transfer descriptors.  The interrupt service routine examines the descriptors to see which ones have completed, and sets operating system even flags associated with the completed transfers. Then it clears the interrupt request.

So long as we use only one pair of IN/OUT endpoints to transfer the 1 millisecond repetitive data, we see no problem.  When we perform output transfers to the endpoint for flash in addition to the 1 millisecond periodic outputs, we start seeing intermittent errors on the 1 ms. output.  The endpoint transferring data every millisecond gets transaction errors in the status for the USB host controller transfer descriptors.  Those transaction errors appear to be recoverable. The transfer completes successfully.  The transaction errors continue at random times after doing a single data transfer on the flash endpoints.  Along with the intermittent but frequent transaction errors on the 1 ms. outputs we sometimes see lost or incorrect data.

My understanding of a transaction error is that the USB device (CY7C68001) did not respond on USB or responded with an incorrect USB token.  That would indicate either a logic error in the (CY7C68001), or check code failures on tokens or output data.  I have not found any configuration of the host controller that explains the intermittent recoverable transaction errors.  Why would communicating to a second output endpoint cause transaction errors on a different endpoint?  Is there some violation of the FIFO handshaking that could explain the transaction errors on USB?  For example, if an OUT FIFO goes from not-full to full without any output data being transferred, would that cause a transaction error. In that case, the CY7C68001 would return ACK instead of NYET in responses to OUT transfer, but then later NAK the OUT data transfer instead of sending ACK as expected.  Would that be considered a transaction error?  Does an output FIFO going from empty to full without any data being put into it cause the CY7C68001 to violate the protocol enough to produce a transaction error in the host controller?  Is there any other scenario that might explain a transaction error detected by the host controller?

The other odd thing about this problem is that a power cycle makes the problem stop occurring until we perform another transfer to the flash output endpoint.  Doing a software restart or hardware reset does not make the problem stop occurring. Our host controller driver is doing a USB reset to the CY7C68001 in both cases.  Our hardware engineer has verified that even on a software restart, the CY7C6801 and the logic connected to that are also being reset via a hardware signal.

We have been able to verify that communicating with either of the pairs of OUT/IN endpoints and not the other avoids the problem.  By synchronizing the transfers for the sets of endpoints, and moving the timing relationship, we can make the problem happen more or less frequently. Even when the transfers are done separately from each other in time the problem still happens.

Since I am the software engineer, I am only somewhat familiar with the CY7C68001. I am mostly concerned about any EHCI configuration or programming errors that might explain the transaction errors.  We are preserving the PING status and data toggle across transfers to each endpoint.  We only use bulk transfers, either output or input, and we only use the asynchronous schedule.  Other than timing, there is nothing different about the transfers at 1 ms. versus the flash transfers.

We have at most three transfers active in the asynchronous list.  The 1 ms. OUT and IN transfers are started at nearly the same time, with the OUT slightly preceeding the IN.  The OUT transfer always completes before the IN transfer, since the input data is not placed into the FIFO until the expected output data has been completely received by the CY7C68001.  The third transfer that may be present in the asynchronous schedule is either an OUT or IN to one of the flash communication endpoints. The only case where the flash transfers took significant time to complete was during a flash erase.  The IN transfer would not complete until the erase completed about 300 ms. later.  We changed the flash communication so that an IN completes almost immediately, within 125 microseconds or less.  Changing the flash IN transfer to use less time on the USB bus did not have any effect, and an OUT to the flash endpoint still caused the other OUT endpoint to get transaction errors continually afterward.

If there are hardware considerations that might explain this problem of transaction errors and incorrect output data, I would like to pass the information on to our hardware engineer.  I can see how a violation of the FIFO handshaking could cause incorrect data, but I can't explain how that would cause USB transaction errors.  My impression is that the USB logic is mostly separate from the FIFO handshaking.

Should we be looking for electrical issues on the USB bus between the host controller and the CY7C68001?  Does this even sound like a problem being caught by error check codes?

Any suggestions will be appreciated.

We are going to propose "CY62148EV30LL-45ZSXIT" as a replacement for our current production renesas SRAM "RMLV0408EGSB-4S2#HA1". while analyzing we found address line pinout A17 and A18 of the cypress part is interchanged when compare to the renesas part.

We have to clarify, is there any impact in our existing design because of this pinout change?

Please explain this. 

I have Psoc cy8ckit-042 connected with 2 SCB Uart ports. One to the PC and the other to a SIM7600A GSM module. Programming and debug for the cy8ckit is via the onboard usb port.

P4.0  and P4.1 connected to the SIM7600. P0.4 and P0.5 connected to the PC via a Silicon Labs CP210x USB to UART Bridge.

I have tried multiple communication programs but Putty works as well as others. I can enter all the AT commands to the sim 7600 from putty and they work fine. But I cannot get the psoc to send commands to the sim 7600 without losing quite a bit of the message. I have tried turning the echo on and off. No difference. I’ve tried delays, no difference.

I’m using an interrupt to initiate a simple AT command to the SIM7600. When the interrupt is initiated, It prints to the PC uart (Putty) and it works fine, but I print to the sim7600 and it loses many of the characters.

A similar setup works fine using Arduino. I have tried many scenarios to get this to work on the PSOC but it does not cooperate.

I am using an interrupt handler for each UART for receiving. The basic program came from your CE224406_PSoC4_UART.pdf.

I have attached an archive of the project. You may ignore the functions that are not being used.

Any suggestions?

Thank-you

Hi All,

I need to connect more than 4 slaves devices to my master SPI Psoc5LP. for that I am planning to use digital Demux/mux and control register something like the attached snapshot.

I have not much idea how to implement control reg and the Mux/Demux. Is there any example that is using Digital Multiplexer/Demultiplexer ?  please share any Example code. 

And other major issue I am facing is that  my one of the SPI component is SD card that is using EMFile Component library. so for EMfile component How I can play with EMfile Component SPI CS(chip select) pin to activate this SD card whenever is required ? because for EMfile all things are defined internally inside the Emfile component library.

Please suggest how I can Activate EMFILe SD card using Demux/mux whenever is required?

  Thanks

*There is a lot of text (hopefully you can learn something) but the question is at the end!

Hi all,

as explained in this previous topic Minimum and maximum overlay thickness for CSX Capsense widgets , a CSX Capsense widget will undergo a capacitance increase (or a rawcount drop) as the finger gets too close to the sensors, hence the importance of picking an overlay with a certain thickness. This effect that we can call signal disparity is explained (even though not mentioned) in the section 7.5 of the capsense design guide for psoc 4 and 6: Effect of Grounding in CSX Method.

I want to try analyzing the exact behaviour of signal disparity on my device. For this, I will test my capsense PCB without any overlay on top of my 3x5 CSX touchpad widget. I am using the CSX tuning code example.

1. Testing without an overlay, with a finger.

Figure 1: Bare PCB, the signal disparity is most important when using capsense this way.

The signal seems to behave the expected way. as I approach my finger, the raw count increases, until I directly touch the PCB. As I start pressing with more force and my finger is squeezed, the raw count quickly drops to 0.

Once I release, there is a weird behaviour I cannot quite explain. It is probably due to the baseline. When I release, the raw counts increase back to a fairly high number and remain high (detecting a touch) even though the touchpad isn't touched anywhere.

Can this be corrected by changing the baseline (I don't exactly understand how to do it?)

Figure 2: Readings from Capsense Tuner UI with a bare PCB

2. Testing with a very thin overlay, with a finger

Figure 3: PCB with a 2mil (0.05mm) thick overlay

I tried adding a 2mil thick kapton tape as an overlay (2mil ~ 0.05mm so 1/10th of min recommended thickness). The behaviour is similar to described above, but the widget is almost usable -- if I do not press my finger too much, the touch reporting in the capsense tuner UI is pretty accurate.

The baseline problem still occurs after removing my finger, but the false touch is much less perceptive. This makes sense, I am keeping the finger at a larger distance than before, so the signal disparity isn't as important.

3. testing with a very thin overlay, with a grounded conductive layer on top

Figure 4: PCB with a 2miloverlay and a conductive copper tape layered on top and connected to ground

I want to have a conductive layer on top of variable overlay thicknesses so I can have a methodical approach to how signal disparity evolves with the overlay thickness.
I am layering a copper tape, connected to ground, over the kapton overlay. The copper tape acts as a grounded conductor (like a finger) and affects capsense signals.

So if I start the MCU with the copper tape grounded, nothing happens as the baseline is set accordingly, and the rawcounts are set to 0.

But if I start the MCU with the copper tape floating, and connect it afterwards, then the capacitance drastically drops as the sensors pair with the grounded copper tape, and the raw counts drastically increase accordingly. This lets me see how much the sensors pair with the conductive layer. I can then repeat with various overlay sizes and determine how distance affects pairing.

Figure 5: Readings from Capsense Tuner UI, left has a 2 mil overlay, right has

I can effectively tell that the pairing is weaker when the overlay is thicker, which seems to make sense as the ground is further away for the sensors to sink into. But somehow I was expecting something different and I don't understand: I am not able to reproduce the 0 rawcount I get when pressing a finger hard on the sensor. I thought the capacitance would be high at low distances, due to signal disparity. Even though I place the conductive layer at 0 distance from the sensors, the raw counts are the highest, but they should be lower with an increase in capacitance as I get too close to the sensors... Why am I not seeing the signal disparity phenomenon with my conductive layer? It works well when testing with a finger as seen in paragraph 1.

Thanks a lot for reading!