AN82716 GPIF Interface and USB_EVENT_RESET

[ErOz_4712216]

Hello,

I connected FX3(master) to FPGA(slave) using AN82716 master_read_write_sync.cydsn project state machine.  My main application is  cyfxmscdemo which is available in the SDK example projects. I modified existing dma channels according to gpif. 

I modified only GPIF Read State machine as follows: DO_IN_DATA state Repeat Count = 127. Because in the original project, it was sending only one 32 bit data and starts over again. I did not understand the meaning of FLAG_C here?. I'm tying this logic 1. In my case, FPGA sends 128 times 32 bit data and then it comes to READ_SHORT_PKT state (I assume).

I can achieve read10/write10 transactions.

However, I noticed that if numBlks in application exceeds 29,  USB event 4(CY_U3P_USB_EVENT_RESET) is generated during read10 transactions after a while (not all the time).  The transaction stops for seconds and application starts again.

Write10 is working fine without any resets.

What could be the reason of this USB_EVENT_RESET?

1) There should be enough space in DMA buffers. I think Max buffer size should be 65520 bytes. I observe errors after   29*512 = 14848 bytes.

2) I suspect from GPIF read state machine, since I modified it. Is there a meaning of sending one data and start over again in AN82716?

Thanks.

[Hemanth]

Hi,

In AN87216, FLAG_C is driven by AutoSlave firmware. FLAG_C indicates that Slave FX3 has no more data to send.

In master_read_write_sync state machine while the state machine is in state DO_IN_DATA, if FLAG_C is asserted by Slave, address counter is checked. If it is not hit, it means that the slave has no more data to fill he current DMA buffer of Master and hence it enters RD_SHORT_PKT where INTR_CPU action is performed. This triggers gpif interrupt callback in the firmware where set wrap up is done to commit partial DMA buffer.

Please note that in original master_read_write_sync state machine, DO_IN_DATA was done for 512 times (not once as you mentioned). Please cross check that the state has COUNT_ADDR action in it, and the counter was initialized to 511 in the beginning. (You can double click on DO_IN_DATA state to see all the actions in it).

And the reason for initializing 511 as count is because DMA buffer size used in Master/Slave firmware was 512 bytes. GPIF bus width used was 8 bit. In your case, the GPIF bus width is 32bit and I am not sure what is the DMA buffer size. So, you have to use the counter corresponding to DMA buffer size. If you do not send partial DMA buffer size from FPGA, then you do not need RD_SHORT_PKT state. After ADDR counter is hit, state machine transitions from DO_IN_DATA to RD_WR_IDLE.

Please correct these and see if you still get RESET event.

Regards,

[ErOz_4712216]

Hi Hemanth,

I understand the FLAG_C usage.

In the AN82716 AutoMaster code, GPIF databus seems to be 32 bit.

In the code (dma init section) the following configurations are set.

If HIGH_SPEED -> size=512,   dma_cfg_size = 512, GPIFInit(Addr/Data) Counter = 127 

(128*32bit =512 byte -> dma_cfg_size)

If SUPER_SPEED -> size= 1024,dma_cfg_size=2048 (size*BurstLenght*DmaSizeMultiplier), GPIFInit(Addr/Data) Counter = 511         

(512*32bit =2048 byte -> dma_cfg_size)  Is it correct?

What is the role of dmaCgf.count?

Let say, FX3(master) wants to read 32 numBlks (32*512 byte) of data from FPGA. (Read10 cmd)

I call the following function. My dmaBuf should hold (32*512 byte). (It should hold up to 65520 bytes)

CYU3PDmaChannelSetupRecvBuf (&glChHandleBulkLpPtoU, &dmaBuf )

Now in SuperSpeed case, how will GPIF Read State machine behave with this function call?

-AddrCounter will count upto 511 allowing that 512*32 bit data read? ADDR_COUNT_HIT becomes one. Will DMA_RDY_TH0 be zero at the same time?  FX3 needs to read more data. So DMA_RDY_TH0 should be 1 but how will the state go to Idle State without READ_SHORT_PKT.  When does DMA_RDY_TH0 become zero?

I got confused. Could you please elaborate on the reading process step by step with this scenario?

[Hemanth]

---

In the AN82716 AutoMaster code, GPIF databus seems to be 32 bit.

In the code (dma init section) the following configurations are set.

If HIGH_SPEED -> size=512,   dma_cfg_size = 512, GPIFInit(Addr/Data) Counter = 127 

(128*32bit =512 byte -> dma_cfg_size)

If SUPER_SPEED -> size= 1024,dma_cfg_size=2048 (size*BurstLenght*DmaSizeMultiplier), GPIFInit(Addr/Data) Counter = 511         

(512*32bit =2048 byte -> dma_cfg_size)  Is it correct?

Yes above is correct. I had checked a modified project (my mistake). In original project, GPIF bus width is 32 bit. The calculation of DMA buffer size above (2048 byte) is also correct in case of super speed.

If you see the firmware, dmaCfg.size = (size * CY_FX_EP_BURST_LENGTH * CY_FX_DMA_SIZE_MULTIPLIER) which are 1024 *1 *2 = 2048KB

---

What is the role of dmaCgf.count?

---

This variable tells how many DMA buffers are allocated to the channel. (In super speed case, in this firmware, it indicates how many 2048 byte sized buffers.)

---

Let say, FX3(master) wants to read 32 numBlks (32*512 byte) of data from FPGA. (Read10 cmd)

I call the following function. My dmaBuf should hold (32*512 byte). (It should hold up to 65520 bytes)

CYU3PDmaChannelSetupRecvBuf (&glChHandleBulkLpPtoU, &dmaBuf )

Now in SuperSpeed case, how will GPIF Read State machine behave with this function call?

-AddrCounter will count upto 511 allowing that 512*32 bit data read? ADDR_COUNT_HIT becomes one. Will DMA_RDY_TH0 be zero at the same time?  FX3 needs to read more data. So DMA_RDY_TH0 should be 1 but how will the state go to Idle State without READ_SHORT_PKT.  When does DMA_RDY_TH0 become zero?

I got confused. Could you please elaborate on the reading process step by step with this scenario?

---

If you want to read 32*512 bytes at once = 16384 bytes, you can configure DMA buffer size to be 16KB. Configuration of GPIF state machine is discussed in next post.

 

[ErOz_4712216]

Another question is,  why do I have to count DATA_CNT and ADDR_CNT in Write/Read GPIF States?

I think DMA_RDY_TH0 and DMA_RDY_TH1 should be enough for state transition DO_IN_DATA and WR_DATA states.

Because, for read case, I call CYU3PDmaChannelSetupRecvBuf (&glChHandleBulkLpPtoU, &dmaBuf ), and I set required amount of data in dmaBuf.size parameter. I expect that DMA_RDY_TH0  will be high until that required amount of data is supplied from GPIF interface.  Am I wrong?

Besides, what could be the possible reasons of USB_EVENT_RESET during read operation from FPGA? I randomly get this event when numBlks are greater than 29. Until that number everything seems ok.

So, I'm not sure whether this RESET is GPIF related or not. Is there any other thing that I should check?

[Hemanth · Accepted solution]

Another question is,  why do I have to count DATA_CNT and ADDR_CNT in Write/Read GPIF States?

I think DMA_RDY_TH0 and DMA_RDY_TH1 should be enough for state transition DO_IN_DATA and WR_DATA states.

---

DMA_RDY_TH0 cannot be used as it indicates buffer full status one clock cycle late. This can cause DMA buffer overrun issue. So use counters and make sure that slave is sending exactly DMA buffer worth data. If that happens, ADDR_CNT_HIT occurs. With this condition, transition from DO_IN_DATA to RD_WR_IDLE. If you do like this, you don't have to use RDY flag and also you do not need RD_SHORT_PKT state - as there is no situation where slave sends shorter than DMA buffer size data. (Please let me know if anything is not clear)

---

Because, for read case, I call CYU3PDmaChannelSetupRecvBuf (&glChHandleBulkLpPtoU, &dmaBuf ), and I set required amount of data in dmaBuf.size parameter. I expect that DMA_RDY_TH0  will be high until that required amount of data is supplied from GPIF interface.  Am I wrong?

---

As discussed above, for ex: to read 32*512 bytes (16KB). Configure DMA buffer size to be of 16KB and then for 32 bit GPIF bus width configure address counter to 4095. Once slave sends 16KB data, ADDR_CNT_HIT happens.

In your case, as you will be using MANUAL_IN or MANUAL_OUT channels, dmaConfig.count can be 0. Only dmaConfig.size matters.

---

Besides, what could be the possible reasons of USB_EVENT_RESET during read operation from FPGA? I randomly get this event when numBlks are greater than 29. Until that number everything seems ok.

So, I'm not sure whether this RESET is GPIF related or not. Is there any other thing that I should check?

---

Is it possible to take a USB trace with hardware USB analyzer?

Note: Along with this post, please also check previous one.

Regards

[ErOz_4712216]

Hello again,

I see the point. In mass storage case, sector count is varible(between 1 to 1024 sector)However I count data at the same time on the FPGA side in order to prevent overrun/underrun issues. Thus I think my gpif interface is Ok since I do not get any errors until the specified sector count.

I'm still trying to trace USB on the host side.  When I check the USB protocol on the host side, I see "Clear feature request" and FX3 creates Reset Event and USB host side retries the same lost (unprocessed) command.

Is there a way to prevent FX3 to create a reset event or bypass it?

There is a pause interval approximately 10 seconds and then FX3 continues to read/write again starting from the lost command. Where should I suspect from?

Further advice on the possible causes of this reset event is appreciated.

[Hemanth]

Hi,

Please try handling of CY_U3P_USB_SC_CLEAR_FEATURE which is in mscdemo example firmware instead of AutoMaster firmware.

If you are already using the same, please share the usb trace which you have taken.

Regards,