131 is an invalid state.
The state numbers should be one of 16 states given in CX3 TRM figure 7.
Can you let us know where in the firmware you are using this API and are you doing UART print of the result of this API? If yes, where are you putting the print?
Which SDK are you using 1.3.3 or 1.3.4?
The CyU3PGpifGetSMState() is called directly from the CyCx3AppDmaCallback() under a CY_U3P_DMA_CB_PROD_EVENT callback type and after successful CyU3PDmaMultiChannelGetBuffer() call.
The values are indeed taken from a UART print out using CyU3PDebugPrint().
0x83 is always printed in the first callback, and immediately after that there is another producer event where the state seems to have recovered (prints as 0x7).
We are using 1.3.4 SDK.
The side effect we are observing from the host side is that there seems to be a swap of the 2nd and 3rd dma buffer transfer.
i.e. we receive in the following order 1st, 3rd, 2nd, 4th, 5th, 6th etc...
Are you using CyU3PDebugPrint() in the DMA callback.
If yes that could be the reason you are seeing the invalid state getting printed. CyU3PDebugPrint() cannot be used in a callback.
Ok, I understand it might not be thread safe etc, it s just that it is pretty consistent and seems to print valid states just not in the first call.
So I am receiving states 131,7,7,2,5,5,17,7,7,2 etc with respective consume events in the between.
Out of curiosity, does bit 7 (0x80) of PIB->gpif_waveform_ctrl_stat mean something? Could it be that 0x83 is state 3 or'ed with an error bit of some sort?
If you think there is no value pursuing this route, I still need to ask.
I am trying to troubleshoot the fore-mentioned issue, where we appear to receive out-of-order transfers.
This seems to be happening consistently either with AUTO or MANUAL DMA transfers.
Can you please give any advice on how to go about troubleshooting this?
A few things to note:
The documentation in CX3 TRM figure 7 is not in sync with the code, the maximum state value that can be is 17 (CX3_WAIT_FOR_FRAME_START_SCK1) and not 16.
Also a number of given state numbers in the documentation do not match with the code, like states 6 and 7.
Please specify that the issue that you are facing with your firmware?
What is the code that you are using/referring here with state machine mentioned in the TRM?
We are using a CX3 to read out a csi camera.
Following more or less the off-the-self SDK (1.3.4) cx3 example cycx3_uvc_ov5640 for how to go about setting up GPIF DMA.
The issues I am experiencing are mentioned above.
Not sure exactly what your question is?
The DMA Channel used in typical UVC application is Many to one - Two Producer Sockets and One Consumer Socket. This can be either AUTO or Manual Channel.
Each producer socket is associated with a set of buffers.
In general GPIF II State Machine starts at SCK0, first buffer associated with SCK0 is filled then switch to first buffer of SCK1 then switch to second buffer of SCK0 then second buffer of SCK1 and so on.
On the consumer side, the available buffers are as follows:
1st buffer of SCK0 - B1 (buffer #1)
1st buffer of SCK1 - B2 (buffer #2)
2nd buffer of SCK0 - B3 (buffer #3)
2nd buffer of SCK1 - B4 (buffer #4)
Hence, the order of buffers that supposed to reach Host PC would be B1, B2, B3, B4 and so on.
As you told that the order in your case is B1, B3, B2, B4, B5, B6 and so on. This is not expected.
Can you please tell how did you confirm that the buffers are coming in this order 1,3,2,4,5,6?
I will check the difference between documented GPIF State Machine, State Machine used in the example code and confirm you.
We have a camera that contains a start and a stop test row with predetermined pattern.
Each subframe is fully contained in 2 buffer lengths. So for every 2 buffers received I am expecting to see a start row at the top of the first buffer and a stop row at the bottom of the second buffer.
In the host I can clearly see 2 start rows in the first 2 buffers followed by 2 stop rows in the following 2.
Post that, I receive correctly full subframes with the start and stop rows as expected.
If you have time I would appreciate it if you could have a look at that: does bit 31 (0x8000) of PIB->gpif_waveform_ctrl_stat mean something? Could it be that when CyU3PGpifGetSMState() returns 0x83 is state 3 or'ed with an error bit of some sort? (based on an older implementation of CyU3PGpifGetSMState() I found here: cypress-fx3-sdk-linux/cyu3gpif.c at master · nickdademo/cypress-fx3-sdk-linux · GitHub ).
I understod that you are suspecting bit 31 of PIB->gpif_waveform_ctrl_stat is sometimes set to 1. This is causing the return status of CyU3PGpifGetSMState to 0x83 instead 0x3.
I checked the source code of CyU3PGpifGetSMState and also TRM. Bit 31:24 of PIB->gpif_waveform_ctrl_stat updates the CURRENT_STATE[7:0] of GPIF. I have not seen any such possibility of bit 31 set to 1.
We need check whether the GPIF is receiving two consecutive START Rows in buffer 1 of SCK0 and buffer 1 of SCK1. Hence, the host is seeing them consecutively instead one START ROW and STOP ROW cosecutively.
Can you please set up a MANUAL DMA Channel and check the data in DMA Callback and confirm?
If we see first two buffers (corresponds to first two producer events) are receiving START ROWS and next two buffers are receving STOP ROWS, then we can conclude that the MIPI bridge is sending them in such away.
Also check whether the sensor is sending in this way for first two frames then sending them correctly?