CYU3P_PIB_ERR_THRx_RD_UNDERRUN in MultiDMA application

[EZ_Engineer]

I am currently trying to write out a 640x 360 image encoded in parallel RGB565 using the FX3. With Infineon's gracious support I've been able to set up a MultiDMA channel that produces data with CY_U3P_UIB_SOCKET_PROD_1 and consumes data with both CY_U3P_PIB_SOCKET_0 and CY_U3P_PIB_SOCKET_1.

I have set up the state machine (attached) to switch between Thread0 and Thread1 every 20 lines. And it looks like that transition is working properly for about 185 lines at which point the output stops:

(the highlighted green measurement counts the number of HSYNC pulses for which I was seeing data)

Initially I thought that maybe the file I transmitted had insufficient amount of data for a whole image but I quadrupled the amount of data and am still only seeing about half the lines being written.

In my debug output I am seeing the following prints:

The error printout complains about a THR1_RD_UNDERRUN but my first writes are done using Thread0:

The state machine should not transition to TH1 until 20 lines have been written (the size of one DMA buffer), yet there is an underrun error before even the second buffer has been committed. Does this mean I am writing data out faster than it's being read from the USB port?

[Rashi_Vatsa · Accepted solution]

Hello,

CYU3P_PIB_ERR_THRx_RD_UNDERRUN error is seen when the DMA buffer is empty but the GPIF state machine still reads the data from the DMA buffer.

Getting CYU3P_PIB_ERR_THR1_RD_UNDERRUN when Read on thread 0 is being done is strange. After going through the firmware,  I noticed that CyU3PDebugPrints is  called in DMA callback. We do not recommend calling blocking call in the DMA callback. Please comment out the API call.

Global variables or events can be used to track the DMA events. Please share the UART debug prints after the changes. Also, call CyU3PGpifGetSMState in CyFxAppThread_Entry and print the value in the for loop to understand the status of the state machine

[EZ_Engineer]

Hi Rashi,

I have removed the DebugPrints in the DMA callback and added a call to CyU3PGpifGetSMState in CyFxAppThread_Entry.

The result is that the program prints DMA_WAIT_T0 until I try to submit a file, at which point the output is:

It's peculiar that only WRITE_LINE_T0 and WRITE_LINE_T1 are showing up. Since the DMA_WAIT_T0 spams things a bit I removed it and this was the output. The image transfer takes place after the "CyFxAppInit complete" print.

Could it be that the state machine is moving much faster than the processor can write out the states? I assume this is because the loop in the thread takes a comparatively long time to print the state to the console and misses other transitions. (Although I'd have expected it to at least catch INIT_FRAME_T0).

A question about the multi-threading. I only instantiated an initial condition for Thread 0 since, for now, I figured that the program would always start with writing data to the T0 DMA buffer. However, I'm thinking that maybe thread 1 is executing its states in parallel with thread 0 and not waiting for thread 0 to make the call to THREAD_TRANSITION_T0TOT1?

[EZ_Engineer]

Here is the modified firmware:

[Rashi_Vatsa]

Hello,

Yes, it is possible that the state transitions are faster than the printing of those states. To understand which state is called for how many times, you can put an action "INTR_CPU" in that particular state (for example WRITE_LINE_T0) and register callback using CyU3PGpifRegisterCallback. Using a variable then the no. of times a particular state is running can be tracked

[EZ_Engineer]

Hi Rashi,

I was able to slow the state machine way down by setting

CyU3PPibClock_t pibClk;
pibClk.clkDiv = 1024;
pibClk.clksrc=CY_U3P_SYS_CLK_BY_16;

And changing the state printout to only printing when there was a change in states. This way I was able to catch all transitions and get a good idea of the flow of the state machine. With that I realized that was writing out one more line than I wanted (21 instead of 20) so that's where the UNDERRUN error came from.

I'm going to leave the state printout here for posterity:

uint8_t prev_state;
void decodeSMstatus(uint8_t state){
 if (state != prev_state){
  switch( state )
  {
    case [STATE]:
     CyU3PDebugPrint(8, "[STATE]\r\n");
     break;
    /* Repeat /*
  }
  prev_state = state;
 }

[Rashi_Vatsa]

Hello,

Glad to hear that the issue is resolved after modifying the state machine!