USB superspeed peripherals Forum Discussions

Hi everyone,

I'm trying to read the i2c registers from MT9M131 CMOS sensor using the FX3 IC. I was reading the UVC_AN75779 example. But this CMOS sensor: MT9M131 is slightly different from MT9M114 used in the example UVC_AN75779:

The address size is 8 bits instead of 16 bits, so I have to change the functions SensorRead2B and SensorWrite2B.

I've started changing the fucntion SensorRead2B, but it doesn't work, so I'm not sure If I doing this issue correctly. According to the datasheet of the MT9M131, this is the scheme of a reading of 16 Bits:

START - Address (0xBA) - ACK - Address2read (For example: 0x02) - ACK - START - Address (0xBB) - ACK - Data MSB  (8 bits) - ACK - Data LSB  (8 bits) - NACK - STOP 

And this is the function I can't achieve to work well:

CyU3PReturnStatus_t SensorRead2B (
        uint8_t slaveAddr,
        uint8_t addr,
        uint8_t *buf)
{
    CyU3PReturnStatus_t apiRetStatus = CY_U3P_SUCCESS;
    CyU3PI2cPreamble_t preamble;

    if ((slaveAddr != SENSOR_ADDR_RD) && (slaveAddr != I2C_MEMORY_ADDR_RD))
    {
        CyU3PDebugPrint (4, "I2C Slave address is not valid!\r\n");
        return 1;
    }

    preamble.buffer[0] = slaveAddr & I2C_SLAVEADDR_MASK;        /*  Mask out the transfer type bit. */
    preamble.buffer[1] = addr;
    preamble.buffer[2] = slaveAddr;
    preamble.length    = 3;
    preamble.ctrlMask  = 0x0004;                                /*  Send start bit after second byte of preamble. */
 

    apiRetStatus = CyU3PI2cReceiveBytes (&preamble, buf, 2, 0);
    SensorI2CAccessDelay (apiRetStatus);

    return apiRetStatus;
}

Any suggestion?

Best regards.

Hi,

I use the samples C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\cx3_examples\cycx3_uvc_ov5640

to send video datas (CYUSB3065).

But now I want to send extra bytes(mpu6500 sensor data) use uvc endpoint,I want to know:

1. If I want to use a new endpoint or Just send it throuth the uvc endpoint .

2. Can you give me some sample code ? 

I see someone asks 

"How to add a new HID interfaces in super speed?",He seems solved the problem,But when I follow the code he writes,

It does not work.

Thanks a lot.

Hi,

I have a Fx3 board connected to FPGA and on boot, we download FPGA image through SPI interface. In firmware, we disable SPI interface through CyU3PDeviceConfigureIOMatrix() once FPGA download is completed. I need to pull up GPIO54 (which is used by SPI)but disabling SPI and pulling up GPIO54  using CyU3PDeviceConfigureIOMatrix() API puts GPIO 54 in tristate for around 600 usec which FPGA doesnot like.

Is there a way i can pull up this line GPIO 54 before disabling SPI. I tried calling CyU3PGpioSetSimpleConfig() but it returns failure as GPIO is used by SPI? 

If not...

Is there a way i reduce this time? 

Thanks in advance

Hi,

i'm using FX3 and the AN75779 example in order to manage a couple of video sensors and to sample analog signals @32KHz using an AD converter connected to the SPI port.

I'm developing this project on CYUSB3KIT-003 board and an APTINA sensor.

Every around 30 microseconds FX3 detects the EOC syncing a MISO falling edge when SCLK doesn't run, then it writes 4 bytes to the ADC and after reads 3 bytes from it. The 4 written bytes change with each sample.

I connected MISO to GPIO45 pin on J7 socket and FX3 polls continously this pin waiting for EOC.

Several issues on this task.

I'm not using yet DMA for SPI transfer: is it possible to sync DMA byte TX & RX on the MISO falling edge, as an external inerrrupt? Maybe using external hardware in order to clean the MISO transactions due to the data transfer. Or better cleaning other pending interrupt requests to SPI DMA?

Moreover, after the detection of the EOC, may the DMA read seven bytes from a TX data buffer and in the same time write seven bytes to a RX data buffer, and then call a callback function?

I created a thread that manages the SPI communication with 8 as priority level, but i noted a great jitter (tens of milliseconds: it seems the transmission of the sensor line data) when the PC host requires the video stream from FX3: how can I avoid this jitter and guarantee the detection of an EOC every 30 microseconds and the execution of the callback?

Connecting MISO and GPIO45, the input signal coming from the ADC greatly reduces itself so i had to put an hardware buffer between MISO and GPIO45 pins. It is possible to avoid this external buffer?
 

Thanks.
Massimo

We are using Cypress FX3 device in our system, hooked in a self power configuration.

While making some testing on performance speed using an Ubuntu system, we are seeing some degradation with respect to a Windows based PC.

Changing power method from self-powered to bus-powered, there seems to be a slight improvement to performance on SS speeds.

Now, I have two questions:

1. Is there any correlation between power method and FX3 speed?

2. Are there any special notes when using Ubuntu, and more specifically an embedded version of it?

Refael.

Hi Cypress Community,

I am designing with the Cypress CYUSB3064-BZXC. It is a MIPI to USB high speed converter BGA.

My question is whether or not I need to have +1.2V power on the pins U3TXVDDQ and U3RXVDDQ if I am NOT using the Superspeed USB 3.0.

I currently have both pins set as No Connects since I'm not using USB 3.0, but I see nothing in the datasheet that says if I can do this or if these power pins still need to be powered.

Thanks for any help or insight you can give! (datasheet attached)

-Stark

Hello,

We have a problem of unexpected data loss (due to some FIFO FULL) when we try to use short packets.
Please note that when we are not using short packets, we have no problem and sustain easily a 350 MB/s stream.

=============  Here is a description of the system  =============
Data is provided by a FPGA (running our code)
Data goes through a FX3 embedded on a PM3 enclustra card
Data then goes to a software of our own

Software side :
  we link to the FX3 1.3.3 CyAPI library
  we use a very efficient reading on a bulk end point, using multiple-circular-scheduled async reads (BeginDataXFer()). We are pretty sure to be very efficient
  we request reads of 4MB
  all reads actually return 4MB, except when a short packet is coming. In this case, one read will return less data, but then the next reads will get 4MB againHello,

We have a problem of unexpected data loss (due to some FIFO FULL) when we try to use short packets.
Please note that when we are not using short packets, we have no problem and sustain easily a 350 MB/s stream.

=============  Here is a description of the system  =============
Data is provided by a FPGA (running our code)
Data goes through a FX3 embedded on a PM3 enclustra card
Data then goes to a software of our own

Software side :
  -we link to the FX3 1.3.3 CyAPI library
  -we use a very efficient reading on a bulk end point, using multiple-circular-scheduled async reads (BeginDataXFer()). We are pretty sure to be very efficient
  -we request reads of 4MB
  -all reads actually return 4MB, except when a short packet is coming. In this case, one read will return less data, but then the next reads will get 4MB again
  -we observe no timeouts (as expected, of course)
  -for information, we want to add short packets in the stream for future development
  
FX3 side :
  -we compile our own FX3 bootimage, based on standard slavefifo example
  -we use the auto DMA mode, with 4 DMA buffers for the channel we use, configured for infinite transfers
  -we use a standard GPIF machine (see attached screenshot)

FPGA side :
  -we emit data, and every 250ms a short packet is (correctly) emitted by pulling PKTEND low. "Correctly" means that we think to respect the documentation about the signals timings.
  
=============  Here is a description of the problem  =============
Software side :
  -several KB are missing almost every 250 ms (see below the explanation when observing the signal lines)
FX3 side :
  -nothing to say. Everything is automatic, so we do not get much information. We tried to bypass the IDLE state of the state machine by adding connections between the SHORT_PKT and the DSS_STATE, but it does not change anything.
FPGA side :
  -we observe the signal lines. Almost at every short packet (but not at every ones), the FLAGB ("dedicated thread not ready") line remains high during dozen of microseconds (which is huge). So, the FPGA fifos will get full since data is not allowed to be transferred during that time. At the rate of emission of data, this is why the software observe several KB of missing data.

See the attached screen shot :
PKEND# goes to '0' along with  the last word of data and SLWR# pulse. So the GPIF state machine interprets it as a short packet. Unfortunatly, the FLAGB signal goes to '0' after around 200µs, indicate that the dedicate thread is not ready to receive data. The FLAGB remains low during around 63 µs and the upstream fifo inside FPGA goes FULL so we loose data.

=============  Our request  =============
We need some guidance about what is going wrong, what could be done...
For information, we plan to use short packets for a special mode where the FGPA emits few data, in unpredicatable amounts. Thus, to avoid timouts and data loss on the software side, we need to use either short packets or zeo-length packets.
Thus, it is true that short packets are not needed in our current design at 350 MB/s, but, we still want it to work in that case before going further. We don't think that it should prevent that mode from working.

I'm currently investigating the FX3 module and have a clear understanding of the interfaces.

One question that may help development... If I were to transmit a RGB image to the Host PC over USB3, is there a specific format suggested to work better with the controller (i.e. U3V) or can this be home-grown? My guess is yes to both with a hit time on development for the home-grown route.

Thank you in advance!