The firewarm(develop with SDK 1.1) and app are work well.Now the newest SDK is Ver 1.1.1 So I build my firewarm with new sdk(1.1.1.1).But it does not  work well .burst read function can not work.It has any notice point in develop from sdf 1.1 to sdk 1.1.1 

 Could you please add more description about your problem.

What application you are using in the PC. What firmware example you are using with FX3. What else is connected to FX3.

Please add more details on your problem.

Thanks,

sai krishna.

 The source code are the same. The diffirent is developed tool (sdk).The firmwam that build with sdk ver 1.1 work well .the firmwam that build with sdk ver 1.1.1 does not work well .

Hi Ayi,

Thanks for sharing more information regarding your problem.

Which example code are you using?. What is the GPIF interface?. Is it configured in 32-bit mode?.

Please let me know.

Thanks,

sai krishna.

 hi RSKV 

Thank for your replay .GPIF 2 is 32 bit mode .The project is develop whit sdk 1.0 by my Colleague.Then I build it with sdk 1.1 and it is work well too . A week ago i update the sdk to V 1.1.1  and  i found the *,img does not work well when burst read size more than 0x330.I think the source code has no problem .what is different with sdk 1.1 and sdk 1.1.1? And i try the example  slfifosync in sdk 1.1.1 (add my code to the example ) then it is does not work well when burst read size more than 0x330 .what can be affect this size ? 

 hi RSKV

I have a small discovery，A file lead to  the problem.The file is "D:\Cypress\EZ-USB FX3 SDK\1.1.1\firmware\u3p_firmware\lib\fx3_release\cyfxapi.a".I copy the same file from SDK v1.1 to cover it and then build to generae the *.img.Then downloa to ram and it is work well.So i think this file's changes lead to my problem,But I don't know  the specific reason ,so can you help me to know the specific reason.and dose it has other function to slove the problem instead of cover 

Ayi,

Can you try your project with the latest SDK that is released few days back. (SDK1.2).

Please let me know the result.

Regards,

sai krishna.

 hi 

I have solve the problem,It is leaded by the DMA size .The fallowing is the source code:

dmaSlFifoConfig.size = size * 16;

            dmaSlFifoConfig.count = CY_FX_SLFIFO_DMA_BUF_COUNT;

            dmaSlFifoConfig.prodSckId = (CyU3PDmaSocketId_t)(CY_FX_EP_PRODUCER_PPORT_SOCKET);

            dmaSlFifoConfig.consSckId = (CyU3PDmaSocketId_t)(CY_U3P_UIB_SOCKET_CONS_0 | CY_FX_EP_CONSUMER_USB_SOCKET);

            dmaSlFifoConfig.dmaMode = CY_U3P_DMA_MODE_BYTE;

            dmaSlFifoConfig.notification = 0;//CY_U3P_DMA_CB_PROD_EVENT;

//            dmaSlFifoConfig.cb = CyFxSlFifoPtoUDmaCallback

            dmaSlFifoConfig.cb = NULL;

            dmaSlFifoConfig.prodHeader = 0;

            dmaSlFifoConfig.prodFooter = 0;

            dmaSlFifoConfig.consHeader = 0;

            dmaSlFifoConfig.prodAvailCount = 0;

            /* Create the channel */

            apiRetStatus = CyU3PDmaChannelCreate (&glChHandleSlFifoPtoU,

                                                  CY_U3P_DMA_TYPE_AUTO,

                                                  &dmaSlFifoConfig);

the first line dmaSlFifoConfig.size = size * 16;the size is base on the usb speed.In order to increace the transfer speed I make the size bigger (*16).And just the (*16) lead the problem.Remove the (*16) and then it work well.But I have  hesitation ,why the DMA size can affect the transfer and it is just in V1.1.1and v1.2. External FPGA write data to the buffer ,when the buffer is full then the data will be commit to PC .If the data size is smaller than the DMA size ,External FPGA will commit the data by PKEND single. Am i right? So i think the buffer size could't  affect the transfer. SO can you help me to know the reason .I am hurry it 

Best Regards 

jia decun 

hello everyone , bad news,Removing  (*16) can solve the problem but with usb 3.0 mode the transfer speed will come down that I don't want .who can help me ?

Ayi,

Please change the starting piece of code in the main function as shown below:

CyU3PIoMatrixConfig_t io_cfg;
    CyU3PReturnStatus_t status = CY_U3P_SUCCESS;
    CyU3PSysClockConfig_t clkCfg = {
            CyTrue,
            2, 2, 2,
            CyFalse,
            CY_U3P_SYS_CLK
    };

    /* Initialize the device */
    status = CyU3PDeviceInit (&clkCfg);
    if (status != CY_U3P_SUCCESS)
    {
        goto handle_fatal_error;
    }

    /* Initialize the caches. Enable instruction cache and keep data cache disabled.
     * The data cache is useful only when there is a large amount of CPU based memory
     * accesses. When used in simple cases, it can decrease performance due to large
     * number of cache flushes and cleans and also it adds to the complexity of the
     * code. */

Let me know the result after doing this modification.

Thanks,

sai kirshna.