GPIF not writing data to socket

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

cross mob
lock attach
Attachments are accessible only for community members.
xyphro
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

 

Hi!

We have a firmware based on AN75779 (UVC Bulk streaming). There are some adjustments to the actual image sensor.

What we notice is, that sometimes (not consistent) with the same binary firmware image, it works very well and sometimes we just get no GPIF payload at all, but just one 12 Byte UVC Header packet per frame.

Investigations have shown, that the GPIF waveform is working perfectly fine (confirmed by toggling CTL outputs and watching them with a logic analyzer). There is a clear ping ponging done between the 2 GPIF threads 0 and 1 and IN_DATA called the expected the expected amount of times.

When logging the 2 GPIF producer Sockets and 1 USB consumer socket register values over time from a second thread, we do see, that when in an operational state:

- The SCK_COUNT data is incrementing for PIB Socket 0 and PIB Socket 1 + UIB as expected
- The STATE of the socket is always active

When we are in a non operational state we see:

- SCK_COUNT of the 2 PIB sockets is constantly ZERO
- The PIB state is sometimes STALL and sometimes ACTIVE
- The UIB is incrementing only once per frame with the expected 12 Bytes of the UVC header (Triggered by Interrupt from GPIF PARTIAL State, calling wrapup, calling indirectly the producer callback

We checked in exactly this situation the GPIF state machine by generating pulses in the 2 data transfer states and they are coming as expected.

The Sensor is clocking the PCLK with 75 MHz.

Could this be an issue of the THREAD controller, that resides between GPIF and DMA socket?
ANY help is appreciated in hints how to debug further.

We checked for return error codes everywhere possible, e.g. the multi DMA setup, but don't get API errors in the non working situation.

The sourcecode can be shared with Cypress, but I don't want to put it in this public forum.

Best regards,

Kai

Attachments:
- APPThread_logfunction.c - The function that creates debug prints. Called every 100ms from within APPThread
  The log prints 3 Socket register and THREAD controller configuration
- Logfile_good_state.txt - A Logfile when "everything works fine" All 3 SCK_COUNT registers are incrementing
- Logfile_nonWorking_state.txt - A logfile from the state where the 2 GPIF socket2 don't receive data, allthough IN_DATA state is confirmed to be called in GPIF statemachine

0 Likes
1 Solution
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Kai,

Please refer to section 10.6.2 of FX3 TRM. 

PIB_INTR :  GPIF_ERR &  PIB_ERR - Firmware clears this bit after handling the error.

Once the interrupt is triggered CY_U3P_PIB_ERROR_EVT event  is set  and the callback in the application is called. As discussed earlier, the error could be because the GPIF is writing to a socket, which is not  intended/setup for write access from GPIF. 

Regards,
Rashi

View solution in original post

0 Likes
14 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

From the description, I understand that for the non working cases the video data is not received and only UVC header is received on the host. Please let me know how frequent is the error seen.

Can you please let me know if the GPIF state machine is the default or a custom state machine? Also, let me know the video resolution streamed using FX3. Is the problem seen on multiple boards or is it reproducible on a single board.

If the GPIF state machine is custom one, please share the same. Please probe and share the FV, LV and PCLK when the issue is seen.

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi, thank you for you very prompt response.

I'm replying on behalf of my colleague who isn't available at the moment.

The error is intermittent, it will work for a few days and then stop working.

It is customised version of the standard state machine, I'm attaching the project files.  The resolution is 624 lines by 2800 pixels.  The frame rate is 30 Hz and the PCLK frequency 75 MHz.

We are currently using a Superspeed Explorer Kit board with our prototype data acquisition hardware plugged into it.  The problem is not limited to one kit board but has been demonstrated on three different samples.  We have no clue as to what causes it stop nor even start working.

We are not using a conventional imaging chip and the sync pulses are unconventional. 

The Frame signal toggles state at the beginning of each frame.

The Line signal is an active line signal that is high during the active period of the line.

I've have attached logic analyser screen captures of the timing pulses, these were recorded from rear of the board to board interconnect when the transfer was not working.  

Can I just stress that even when no data is pushed into the socket, the state machine is operating correctly.  This is verified by the setting and monitoring CTL outputs in from specific states as you will see in the GPIF designer file.  But no data is pushed into the socket as verified by the diagnostics in our previous post. 

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

Can I just stress that even when no data is pushed into the socket, the state machine is operating correctly.  This is verified by the setting and monitoring CTL outputs in from specific states as you will see in the GPIF designer file.  But no data is pushed into the socket as verified by the diagnostics in our previous post.

>>  I couldn't understand this. By "no data is pushed into the socket" I understand that the Frame and Line are not driven or is frame and line are driven but there is not valid data on the data lines (i.e. GPIF bus). Can you please restate this.

Also, can you check the GPIF state when the ZLP is committed (i.e. only UVC header is sent to host)? I understand that MANUAL DMA channel is used in the firmware. Please let me know the status/count of producer and consumer events when the issue is seen. Also, let me know the DMA buffer size used for the application.

Regards,
Rashi
0 Likes
xyphro
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Dear Rashi,

thanks for your responses. Socket is a Cypress terminology. Sockets are described in Section 5.5.5 of the FX3 TRM and are either producing data or consuming data, depending on how things are setup. Those are logical data endpoints used by the DMA subsystem.

In our concrete case we have 2 PIB producer sockets (SOCKET_0 and SOCKET_1) that are assigned by your GPIF tool in an implicit way to GPIF socket threads THREAD_0 and THREAD_1. The multidma is then setup to get data from those 2 sockets and transfer it to the UIB consumer socket 3 - which is Bulk endpoint #3. This transfer happens in a manual way once the DMA_BUFFERS (see Section 5.5.5) are filled by the DMA subsystem raising an interrupt which is setup by your API to trigger a callback function. This callback function does commit the DMA buffers towards the UIB socket (including the 12 byte FW deffined header).

Let me explain more detailed our issue again:

We are having a correctly working GPIF statemachine that takes data from the DQ0..15 pins in a synchronized way to 2 sync signals. This data is expected to leave via Endpoint 3 the FX3 towards the PC whenever the Host requests Bulk data.

This is indicated by the red path. The left side I copied from Figure 7-1 from the FX3 TRM showing the terminology of Threads and sockets, that I refered to earlier:

xyphro_0-1628008274944.png

However, allthough our sync and data signals, that we generate are correctly present and the GPIF-II statemachine is confirmed to operate as expected (calling IN_DATA 8184 times for THREAD0 and IN_DATA 8184 times for THREAD 1 in a ping pong fashion), we see no data coming in some situations. The exact cause is unknown and we would like to understand what happens to be able to fix it.

What we confirmed:

  • The Host is correctly requesting Bulk transfers from EP3 in a continous fashion using its UVC class driver.
  • We are not seeing ZLP beeing generated on the bus as you suspected.
  • To understand if the DMA part is working we looked into the statistics and status of the 2 PIB producer sockets and 1 UIB sockets.
    If you manage to find time it would be nice, if you can look into the first post zipfile with information on it.
    • Here we see that when the FX3 is properly working, the producer and consumer sockets are correctly incrementing their byte counters.
    • We also see that when the FX3 is NOT properly working, that the producer AND consumer socket byte counters keeo continously the value 0.
      • We also confirmed, that in NON working state the GPIF is correctly working by generating output pulses on output lines within the 2 states that call the GPIF IN_DATA action.
        This would have to increment the SOCKET_0 and SOCKET_1 data counters accordingly, which we don't see.

We are not expecting you to solve our full problem, but to understand in which way we can debug further.

So what could potentially cause the GPIF IN_DATA not to generate any increment in the PIB SOCKET data counters?
Or: What else could we do to get a grip on the root cause?

 

To give direct answers to your questions:

- the GPIF state machine (see Peters attachments in the post) does not commit anything to USB. Also AN75779 does not have a mechanism to commit from GPIF packets towards USB. This is working manually as otherwise we could not add the SW defined 12 Byte UVC header - as in AN75779.

- In the errorneous case there is only a single producer event generated per frame. This event is caused by the GPIF statemachine that raises an interrupt every frame. So when we receive the interrupt, we call the PIB sockets wrapup as the buffer is only "partially filled" and this wrapup call triggers the producer event. As the GPIF seems not to push any data into the thread0/1 and socket 0/1 the dma.buffer property is ALWAYS 0. We debugged this place extensively too which lead us towards looking into the PIB and UIB socket data count and status behaviour that we described earlier.

 

Do you have GPIF / DMA experts, that could look into this thread?

Best regards,

Kai

 

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Kai,

Thank you for the details.

I understood the problem now. When the issue is seen the GPIOs are driven properly but the data is not received which indicates that the GPIF SM is not stuck but the PIB sockets have some problem.

In that case, please register for PIB and GPIF error interrupts using CyU3PPibRegisterCallback API to check the errors  on the PIB side. With this we will know the error condition. The attachments shared in the description post of the thread are not clear. Please let me know how and from where are these values read.

This is from the non working log file, please let me know what are these values and how are these values logged. I understand for this case, the GPIF SM is working but only IN_DATA doesn't push the data to socket.

C40018 0 84510000 | C0001C 0 84508000 | 880010 1DA0 84908000 |

Regards,
Rashi
0 Likes

Hi Rashi

Thank you very much we will get on it.

The debug prints were created from the code snippet included in our original attachment, here is the debug function for your convenience

#define REGACC(addr) (*((volatile uint32_t *)(addr)))
#define UIB_BASE (0xE0038000) /* Base for USB DMA sockets */
#define PIB_BASE (0xE0018000) /* Base for GPIF DMA sockets */
#define SCK_DSCR_OFF (0x0) /* OFFSET */
#define SCK_SIZE_OFF (0x4) /* OFFSET */
#define SCK_COUNT_OFF (0x8) /* OFFSET */
#define SCK_STATUS_OFF (0xc) /* OFFSET */

uint32_t arr[16];

void debug_function(void)
{
uint32_t i, v1, v2;

/* Add GPIF Socket 0 status */
arr[0] = REGACC(PIB_BASE + 0x80*0 + SCK_DSCR_OFF);
arr[1] = REGACC(PIB_BASE + 0x80*0 + SCK_COUNT_OFF);
arr[2] = REGACC(PIB_BASE + 0x80*0 + SCK_STATUS_OFF);

/* Add GPIF Socket 1 status */
arr[3] = REGACC(PIB_BASE + 0x80*1 + SCK_DSCR_OFF);
arr[4] = REGACC(PIB_BASE + 0x80*1 + SCK_COUNT_OFF);
arr[5] = REGACC(PIB_BASE + 0x80*1 + SCK_STATUS_OFF);

/* Add USB Socket 3 status (= Video endpoint socket) */
arr[6] = REGACC(UIB_BASE + 0x80*3 + SCK_DSCR_OFF);
arr[7] = REGACC(UIB_BASE + 0x80*3 + SCK_COUNT_OFF);
arr[8] = REGACC(UIB_BASE + 0x80*3 + SCK_STATUS_OFF);

arr[9] = REGACC(0xE00140FC+0*4);
arr[10] = REGACC(0xE00140FC+1*4);

i=0;
for (i = 0; i < 11; i++) {
CyU3PDebugPrint(4, "%x ", arr[i]);
if (i % 3 == 2)
{
CyU3PDebugPrint(4, "| ");
}
}
CyU3PDebugPrint(4, "\r\n");
}

0 Likes

Hi Rashi,

thanks for your recommendation.

We managed to make a test.

First: This is how we setup the callback:
CyU3PPibRegisterCallback(&PibCaB, 0xfffffffful); See [1]

And this is our callback function code, that we provide as parameter to the registerCallback function:
void PibCaB (
CyU3PPibIntrType cbType, /**< Type of interrupt that caused this callback. */
uint16_t cbArg /**< 16-bit integer argument associated with the interrupt. */
)
{
CyU3PDebugPrint(4, "PibCB: %d %x\r\n", (uint32_t)cbType, cbArg);
}

We investigated the behaviour in 2 conditions:

  • FX3 is working properly and delivering data to EP3 (and showing expected picture). We do get prints like this:
    PibCB: 4 0x1a, so an error with CYU3P_PIB_ERR_THR1_SCK_INACTIVE enum value. We expect this to be a property due to the fact that we have an incomplete buffer beeing wrapped up and commited and no "unexpected error", but expected and good behaviour.
    The errors are also coming at an approximate rate of 1 error per FRAME (guesstimated).
  • FX3 is not working properly and no data received on EP3. Here it gets "special". We do get prints like this back:
    PibCB: 4 1002 <- Note 1002 is printed in hex, so this is 0x1002
    PibCB: 4 1001 <- Note 1001 is printed in hex, so this is 0x1001
    They are coming at extremly high rate.

    Now the question is: What kind of error is this? It is kind of unexpected to see such high numbers.

Best regards,

Kai

[1] with 0xfffffffful we efffectively have CYU3P_PIB_INTR_ERROR and CYU3P_PIB_INTR_DLL_UPDATE enabled ( I checked the FX3 Linux SDK available on Githu for reference).

Updated: After heavy research I see, that the callback cbArg is actually the content of the PIB_ERROR register. Here is also a bitfield for GPIF_ERRORS in the upper bits. So what we get is a value 0x4 in the error case (0x1000 as register value decodes to 0x4 for the GPIF_ERRORS bitfield).
Under which condition can this GPIF ERROR error 4 occur?

0 Likes
xyphro
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Sorry Rashi, another question. The PIB_INTR register has fields for DLL lock/unlock. Is there a DLL [1] used in the GPIF context? Is it clocked based on PCLK signal?

or can you confirm, that the DLL is only used for SD/MMC purposes?O[1] delay locked loop

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Kai,

Please refer to section 10.6.7 of FX3 TRM.

As the values are 0x1002/1

GPIF_ERR : DMA_DATA_WR_ERROR

PIB_ERR:  Write being done to a read socket or read being done to a write socket

- If you check the cyu3pib.h for CyU3PPibErrorType, then you will find that number 5 corresponds to CYU3P_PIB_ERR_THR0_WR_OVERRUN and if you check CyU3PGpifErrorType in the same file (cyu3pib.h) then you can see that 0x1000 corresponds to CYU3P_GPIF_ERR_DATA_WRITE_ERR.

Regards,
Rashi
0 Likes

 

Hello Rashi,

thanks for the information. Do I understand this right:
This error means, that the GPIF is writing to a socket, which is not  intended/setup for write access from GPIF?

Do you know, if this error flagging will be permanent, in case such an error would only be present for a short amount of time during the startup phase (e.g. potential race condition of GPIF/Multidma startup).

Best regards,

Kai

 

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Kai,

This error means, that the GPIF is writing to a socket, which is not  intended/setup for write access from GPIF?

>> Yes, this can be true for your application

Do you know, if this error flagging will be permanent, in case such an error would only be present for a short amount of time during the startup phase (e.g. potential race condition of GPIF/Multidma startup).

>> As per the TRM, the error can be triggered by hardware i.e. the R/W access by hardware and R access by software. I will check when this error will be cleared.

Regards,
Rashi
0 Likes

Hi Rashi,

did you get a feedback on this?

Do you know, if this error flagging will be permanent, in case such an error would only be present for a short amount of time during the startup phase (e.g. potential race condition of GPIF/Multidma startup).

Best regards,

Kai

0 Likes
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Kai,

Please refer to section 10.6.2 of FX3 TRM. 

PIB_INTR :  GPIF_ERR &  PIB_ERR - Firmware clears this bit after handling the error.

Once the interrupt is triggered CY_U3P_PIB_ERROR_EVT event  is set  and the callback in the application is called. As discussed earlier, the error could be because the GPIF is writing to a socket, which is not  intended/setup for write access from GPIF. 

Regards,
Rashi
0 Likes

Thanks a lot Rashi for your support!

0 Likes