8 Replies Latest reply on Apr 15, 2019 10:30 PM by bhchc_3447926

    Re-invoke old post https://community.cypress.com/thread/37344


      There are some persons over cypress forum which close the thread. I don't know why the moderator allows them.

      I would like to reinvoke this post,


      FX3 Interrupt Endpoint + Custom Linux Driver weird behaviors


      Recently I came across this problem once again and after debugging carefully I found two major points.


      1) The fast interrupt which is working fine with our custom Linux and Windows Device Driver, the driver can receive interrupt data on interrupt EP.

      Here fast interrupt means, when I perform some activity on our hardware board to generate an interrupt, it produced within a couple of micro/mili seconds.

      For example, FPGA+microcontroller subsystem on board, let say I2C/SPI peripheral attached to the microcontroller and I need to configure that peripheral so for that, I need to write 1st on FPGA register and FPGA logic will start communication with Microcontroller and ultimately microcontroller will start to initiate I2C/SPI xfer. After complete such xfer, it will raise interrupt to FPGA and FPGA toggle GPIO to FX3 chip and put interrupt hex code toward interrupt Endpoint. such operation in my case takes few milliseconds.


      2) The slow interrupt which is not working fine with our custom Linux and Windows Device Driver, the driver cannot receive interrupt data on interrupt EP.

      Here slow interrupt means, when I perform some activity on our hardware board to generate an interrupt, it produced after a couple of seconds.

      For example, If I have DDR4 memory attached on board and I need to scan entire memory to validate that memory is working fine or not. For that I have to configure register on board to start scanning, now custom FPGA logic will start scanning and after 7-8 seconds it will produce test done interrupt via GPIO toggle to FX3 chip.


      To eliminate above problem I have two solution.

      Each solution is to raise a question for me, I would expect an answer respectively from this forum.


      1) Solution - 1 (Actaully workaround for me as of now):

      If I fire below version of dummy vendor command before generating a slow interrupt(DDR4), I can receive interrupt on interrupt endpoint(DDR4 test done interrupt).

                          case 0xBF:

                              CyU3PDebugPrint(4,"Dummy 0xBF cmd received\r\n");

      without request completion.


      the interesting fact over here is that, if I fire below version,

                          case 0xBF:

                              CyU3PDebugPrint(4,"Dummy 0xBF cmd received\r\n");


      with request completion than on interrupt endpoint, the slow interrpt is not received.


      The fast interrupt is working fine if I fire or not fire. Which is actually expected.


      Q - What is the relationship between vendor command with no request completion and a slow interrupt is coming to host/PC?


      2) Solution-2 (I believe this is an actaul solution):

      If I change bInterval field of endpoint descriptor from 0x04 to 0x0B then all interrupt coming fine and I don't need above kind of workaround.


          /* Endpoint descriptor for consumer EP2 (0x82) */

      0x07,                           /* Descriptor size */

      CY_U3P_USB_ENDPNT_DESCR,        /* Endpoint descriptor type */

      CY_FX_EP_2_IN,              /* Endpoint address and description */

      CY_U3P_USB_EP_INTR,             /* Bulk endpoint type */

      0x02,0x00,                      /* Max packet size = 32 bytes */

      //0x04, OLD one which is not working fine for slow interrupt

          0x0B,                           /* Working fine for both fast and slow interrupt ... Servicing interval for data transfers : 1 - Every micro-frame. */





      /* Super speed endpoint companion descriptor for consumer EP2 (0x82) */

      0x06,                           /* Descriptor size */

      CY_U3P_SS_EP_COMPN_DESCR,       /* SS endpoint companion descriptor type */

      0,     /* Max no. of packets in a burst(0-15) - 0: burst 1 packet at a time */

      0x00,                           /* Max streams for bulk EP = 0 (No streams) */

      0x02,0x00,                      /*  Bytes per Service interval for the Int EP : 0 for bulk */


      Now above solution raise question,

      Q - Why the higher value of polling interval working fine for slow interrupt?

      I know 0x04 bInterval value means 1ms as per USB 3.0 spec. formula (2^(bInterval -1) * 125uS)

      and 0x0B bInterval value means 128ms.

      Why it is affacting and all kind of interrupt I can received on interrupt pipe is mystery for me.


      I hope this time I can get good answer!