Interfacing FX3 to parallel ADC

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Vazovski
Level 2
Level 2
First solution authored 10 replies posted 5 replies posted

Hello,

I'm trying to implement data acquisition from parallel CMOS 12-bit ADC using FX3 (CYUSB3014).
My setup is the following:
- FX3 is clocked via 19.2 MHz XTAL;
- FX3 frequency is 403.2 MHz (clockConfig.setSysClk400 = CyTrue);
- GPIF II is configured to latch 16-bit data, bits [15:12] are pulled-down;
- GPIF II Settings: Used I2C & UART, Synchronous Master, Positive clock, LE, 16 bit, 1 input signal;
- PIB is configured to generate PCLK with divider 6 - 67.2 MHz output approx. I've read KBA210733 before doing it;
- GPIF II State machine is similar to AN75779's, except that I have only 1 input signal (pic 1). Data is sampled when the WE signal is active. DATA_COUNT limit is 15871 = 0x7C00 / 2 - 1 = 0x3E00 -1. Ping-pong scheme is used;
- DMA config: 2 Producer Sockets, Buffer size - 0x7C00 (31'744) bytes, buffers count - 4, Type - Auto Many to One, No callback is used;
- Cache control: CyU3PDeviceCacheControl(CyTrue, CyFalse, CyFalse).

During developing PC app, based on Streamer, I performed some tests. ADC's input is connected to generator, which generates sin @ 10 kHz. USB Queue size - 16, Packets per Xfer - 32. Tested with other values, the problem remains.

So, the problem is that data streamed from ADC is corrupted (pic 2, pic 3 - zoomed). An interesting point - corrupted sample # is 126'976 (zero based). But! 126'976 = 0x1'F000 which is 0x7C00 * 4. I've tested with other buffer sizes and counts, corrupted data always located at index BUF_COUNT * BUF_SIZE.

Also I've tested different GPIF PCLK values and both GPIF Interface types (master & slave), the problem remains.

Please help me to deal with it!

Regards,
Nick

Pic 1 - State MachinePic 1 - State Machine

 

Pic 2 - Data corruptionPic 2 - Data corruption

 Pic 3 - Data corruption zoomedPic 3 - Data corruption zoomed

 

0 Likes
1 Solution

Hello Rashi,

Thread can be closed, the problem is solved, cause - Cypress USB driver.

Regrads,
Nick

View solution in original post

0 Likes
9 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

From the details provided, I understand that data corruption is seen when data is written to socket 1 for the second time (4th buffer).

To debug the issue, please register for PIB error using CyU3PPibRegisterCallback and check if any PIB error is seen when the issue occurs. If possible, please capture the trace on the GPIF interface when the issue is seen.

Also, please let me know what is done in the firmware when INTR_CPU is triggered in the full_buff_sock state.  Kindly, confirm if there are any partial buffers sent by the ADC. If yes, how frequent are the partial buffers sent?

Please let me know the PCLK frequency used when the issue is seen

Regards,
Rashi
0 Likes

Hello


> From the details provided, I understand that data corruption is seen when data is written to socket 1 for the second time (4th buffer).

To my mind, data corruption is seen after the data is written to socket 1 for the 2nd time. Cause data corruption offset index is 0x1'F000, so, it's after the 4th buffer commit.


> To debug the issue, please register for PIB error using CyU3PPibRegisterCallback and check if any PIB error is seen when the issue occurs.

After PIB callback registration FX3 is crashed somewhere in CyU3PConnectState

    apiRetStatus = CyU3PGpifLoad((CyU3PGpifConfig_t *)&CyFxGpifConfig);
    if (apiRetStatus != CY_U3P_SUCCESS) {
        log_severe(4, "Loading GPIF Configuration failed, Error Code = %d\r\n", apiRetStatus);
        CyFxAppErrorHandler(apiRetStatus);
    }
    
    CyU3PPibRegisterCallback(PibEventCallback, 0xFFFF);
    
    /* Register the GPIF State Machine callback used to get frame end notifications.
     * We use the fast callback version which is triggered from ISR context.
     */
    CyU3PGpifRegisterSMIntrCallback(cy_fx_gpif_callback);

 

> Also, please let me know what is done in the firmware when INTR_CPU is triggered in the full_buff_sock state. Kindly, confirm if there are any partial buffers sent by the ADC. If yes, how frequent are the partial buffers sent?

Here is the GPIF callback's code:

static void cy_fx_gpif_callback(uint8_t current_state)
{
    switch (current_state) {
        case PARTIAL_BUF_SOCKET_0:
            CyU3PDmaSocketSetWrapUp(CY_FX_DSC_PRODUCER_SOCKET_0);
            break;
        
        case FULL_BUF_SOCKET_0:
            break;
        
        case PARTIAL_BUF_SOCKET_1:
            CyU3PDmaSocketSetWrapUp(CY_FX_DSC_PRODUCER_SOCKET_1);
            break;
        
        case FULL_BUF_SOCKET_1:
            break;
        
        default:
            /* This should not happen. Do nothing. */
            return;
    }
    
    CyU3PGpifControlSWInput(CyTrue);
    CyU3PGpifControlSWInput(CyFalse);
}

ADC produces data continuously, as it being clocked forever long. So, the endless stream is sent to GPIF bus.

> Please let me know the PCLK frequency used when the issue is seen

In current setup PCLK is 403.2 / 6 = 67.2 MHz. I've tested the frequencies as low as 33.6 MHz, error still occurs.
Also I've tried to increase buffer size on PC: Packet per Xfer = 256, USB Queue size = 64, error still occurs.

Regards,
Nick

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Nick,

Thank you for the details.

From the logs, it seems that there is an overflow on both threads 0 & 1. 

Please share the DMA channel configuration used in the firmware and the GPIF II state machine file (.cyfx)

Also, let me know if it is possible to do a test with PCLK >80 MHz

Regards,
Rashi
0 Likes

Hello Rashi,

Thanks for your reply.

> From the logs, it seems that there is an overflow on both threads 0 & 1.
Yes, both of them have an overflow. But the number of overflow is much more less than the number of packets transferred. I think, overflow only occurs at the start of the transmissions.

> Please share the DMA channel configuration used in the firmware and the GPIF II state machine file (.cyfx)
GPIF II project and DMA initialization code are attached in zip archive.

> Also, let me know if it is possible to do a test with PCLK >80 MHz
ADC used for test purposes can't work at frequencies above 65 MHz, but I can replace it with something else, like FPGA or CPLD for producing counter or sin samples. So, theoretically I can test with any frequency up to 100 MHz.

Regards,
Nick

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Nick,

The GPIF state machine looks fine.

Is it possible to problem the lines on the GPIF interface? If yes, please share the traces for the same.

Also, can you let me know the number of producer events and consumer events (in DMA callback for AUTO_SIGNAL channel) when the overflow is seen?

 So theoretically, I can test with any frequency up to 100 MHz.

>> Please let me know the results. Please note the DLL can be disabled for PCLK frequency >80MHz

Regards,
Rashi
0 Likes

Hello Rashi,

Thread can be closed, the problem is solved, cause - Cypress USB driver.

Regrads,
Nick

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Nick,

Glad to hear that the problem is solved

Can you please give the details on how the Cypress USB driver caused the issue?

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Here's the attachment

0 Likes

Log from PIB callback:

Request to start data stream
CYU3P_PIB_ERR_THR0_WR_OVERRUN
CYU3P_PIB_ERR_THR0_WR_OVERRUN
CYU3P_PIB_ERR_THR0_WR_OVERRUN
CYU3P_PIB_ERR_THR0_WR_OVERRUN
CYU3P_PIB_ERR_THR0_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
CYU3P_PIB_ERR_THR1_WR_OVERRUN
Data stream abort requested
CYU3P_PIB_ERR_THR0_SCK_INACTIVE
CYU3P_PIB_ERR_THR0_SCK_INACTIVE
CYU3P_PIB_ERR_THR1_SCK_INACTIVE
0 Likes