GPIO control by GPIF on FX3

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

cross mob
Anonymous
Not applicable

I want the GPIF state machine to control some GPIO outputs. 

   

Using GPIF-II designer I have configured an output pin, GPIO[25] as initially LOW (active HIGH), and within the GPIF state diagrams I have added a DR_GPIO to each state that asserts the output pin.

   

Once the GPIF is initialised I expected GPIO[25] to go HIGH, but it doesn't.

   

Any pointers as to where I may be going wrong?

0 Likes
2 Replies
Anonymous
Not applicable

A bit more information on where I'm having the issue....

   

I am using 'Cypress EZ-USB FX3 Video Class Example - AN75779' and I wanted a GPIO output to indicate which state of the state machine I am in. I have modified 'ImageSensorInterface.cyfx'. Using GPIF-II Designer 'Interface' tab, I have added a definition for an Output signal as:

   
        
  • GPIO to use: GPIO_25
  •     
  • Initial value: Low
  •     
  • Output type: Early
  •     
  • Polarity: Active High
  •     
  • Signal mode: Assert
  •    
   

From within the StateMachine tab I have added DR_GPIO action to the IDLE state as:

   
        
  • Output type: Early
  •     
  • Signal mode: Assert
  •    
   

The GPIF-II prkect builds OK and I have copied the 'cyfxgpif2config.h' file into the USBVideoClass project and re-built the project.

   

I have added a few 'CyU3PDebugPrint' lines to the project and hence I know that GPIF is being initialised OK and started. I have connected VLC to the FX3 device, and I can see that I am getting video stream events, BUT GPIO[25] (CTL[8]) never gets set HIGH. I expected GPIO[25] to be set HIGH on entering from START -> IDLE state. 

0 Likes
Anonymous
Not applicable

OK, I have now managed to get access to a scope and I now understand what I am seeing...after reading the documentation.

   

I expected that once the state that ASSERTED the GPIO pin had been entered, that the GPIO[25] would be  asserted HIGH, and remain HIGH. I now understand that this assumption was incorrect. According to the documentation, the GPIO pin will only be ASSERTED for as long as it remains in that state. As soon as you leave the state, the GPIO pin gets DE-ASSERTED. Take a look at the TIMING SIMULATION within GPIF-II Designer, and you will see what I mean.

   

Now, for the even more confusing bit. If you want the GPIO pin to remain being driven you have 2 options:

   
        
  • Add the DR_GPIO Assert action to every state within the state diagram
  •     
  • or
  •     
  • Instead of using a DR_GPIO Assert action, use a single DR_GPIO Toggle action. Yes you use a SignalMode set to TOGGLE in order to get a steady-state asserted GPIO pin. 
  •    
   

What a confusing use of terminology: TOGGLE = steady-state!!!!

0 Likes