FX3 dma_rdy_th

[Anonymous]

Hi,

   

I'm prototyping a system using the FX3 Superspeed Explorer kit and the FMC interposer board to interface with an FPGA. I've reused code from the USBBulkLoopManual example to get a state machine up and running which allows me to write/read single 32-bit words to/from the FPGA using the CyU3PGpifWriteDataWords() function and OUT_REG0_VALID trigger. The purpose of this interface is to configure registers within the FPGA, it's working pretty well and I'm happy with it's operation. It uses a CY_U3P_DMA_TYPE_MANUAL DMA channel and a callback for writing to and reading from the GPIF interface/state machine.

   

Now I want to add another DMA channel connected to a new OUT USB endpoint and the GPIF. This will be a CY_U3P_DMA_TYPE_AUTO DMA channel and the purpose of this new channel is to route high-speed data to the FPGA. I've added the OUT endpoint (0x02) and created the new DMA channel linking CY_U3P_UIB_SOCKET_PROD_2 to CY_U3P_PIB_SOCKET_2 (I'm re-using code from the AN87216 firmware examples). Also I've added a new state to my state machine which is triggered by DMA_RDY_TH2. The issue I'm having is that DMA_RDY_TH2 never seems to be set. My state machine loops around between various idle states checking if the OUT_REG0_VALID or DMA_RDY_TH2 triggers have been set. The DMA_RDY_TH2 trigger should cause the state machine to jump into a state from which there is no return i.e. the state machine should just get stuck there (I'll elaborate my state machine to do something useful once I can get to the bottom of why DMA_RDY_TH2 isn't being set). My firmware regularly prints out the current GPIF state using CyU3PGpifGetSMState() so when I write data to my new OUT endpoint I'm expecting the GPIF state to be reported as being my newly added state and it should just stay there for ever. However, this does not happen.

   

In an effort to debug the issue I switched the new DMA channel type to CY_U3P_DMA_TYPE_MANUAL and added a callback for it thinking that maybe there was something wrong with my new USB endpoint. When I send data to my new USB endpoint using the "USB Control Centre", my callback triggers and I call CyU3PDmaChannelCommitBuffer() to send the data to the consumer (CY_U3P_PIB_SOCKET_2) so my endpoint->DMA link looks to be good but when I call CyU3PGpifGetSMState() my state is still not what I would expect it to be.

   

I don't think I've reconfigured the socket-thread mapping anywhere so I don't know why it isn't working. The data I'm writing is the 8192 byte "8192_Count.hex" included in the AN87216 firmware example. My DMA channel size is 1024 and the count is 16. Any thoughts on why DMA_RDY_TH2 doesn't seem to be triggering? Is there some way I can read the state of DMA_RDY_TH2 in the firmware rather than relying on reading the current state of the state machine to detect the trigger?

       

Thanks,

   

Eamonn

[Anonymous]

 Hi EWalsh,

   

Unfortunately, there is no way in the firmware to check if DMA_RDY_TH2 has been triggerred other tha reading the states. There is buffer bit, which tells whether the buffer is committed or not. But since you are getting callbacks, this bit should be set

   

Can you please provide you state machine and firmare. We will check it and also try to reproduce the issue.

   

Regards,

   

- Madhu Sudhan

[Anonymous]

Hi,

   

Sorry for the delay in getting back to you. I realised my mistake, I had a LOGIC_ONE trigger exiting the stage from which I also had the DMA_RDY_TH2 trigger and the state machine always follows a LOGIC_ONE trigger regardless of other triggers connected to a state. Therefore it was never responding to DMA_RDY_TH2. Replacing the LOGIC_ONE with a !DMA_RDY_TH2 solved my issues.

   

Thanks,

   

Eamonn

   

p.s. it might be a good idea to update the GPIF tool to throw an error if someone connects a LOGIC_ONE and another trigger to a state because it will never follow the other trigger

[Anonymous]

Thanks for the feedback.

   

We will look to include this as a warning in future upgrades to the tool.