FX3 camera board has high sensitivity to USB3 errors

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

cross mob
TePl_1066611
Level 3
Level 3
25 replies posted 10 replies posted 10 sign-ins

We have an FX3 based camera board that is using Bulk transfers to send uncompressed data from a 12 megapixel imager. The design has always been unstable, as the slightest USB error will cause it to crash the camera and/or software. A recent test with a fixed pattern generator in the FPGA gives very similar results, but our USB analyser shows no CRC errors, only the occasional 'Running Disparity Error' which it says are just warnings. However, these warnings still seem to be crashing the link. I would have expected the Bulk mode error correction to deal with this sort of problem, but apparently not. Does anyone have a suggestion as to why the system is so sensitive to errors? Thanks!

0 Likes
1 Solution

Hello Terry,

After some debugging I found that more than 4MB data( ~17MB) is requested by the host application.

Please refer to GetXferSize API in CyApi Programmer's reference or  Xfersize() in CYUSB.NET programmer's reference which mentions maximum transfer size limit set into cyusb3.sys driver.

The reference guide for CyAPI.lib is available at C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\doc\SuiteUSB\CyAPI.pdf and the reference guide for CyUSB.dll is available at C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\doc\SuiteUSB\CyUSB.NET.pdf.

For Bulk transfers cyusb3.sys sets the limit  to 4MB.

To transfer the whole frame you can transfer/requests chunks of 4 MB video data from the device.

Please use the driver shared in this thread Solved: Win10 specific issue in data transfer from an FX3 ... - Cypress Developer Community . The driver is not signed hence can be used when PC in test mode.

Edited: For USB 2.0 (high speed), the maximum BULK transfer supported is 4 MB USB Bandwidth Allocation - Windows drivers | Microsoft Docs.  so the host application should requests for chunks of 4 MB

Regards,
Rashi

View solution in original post

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

Hello,

From the description I understand, that when USB errors are seen the application crashes.

Please let me know more details on the application and the behavior seen on the device side

- Does, the device enumerates again, or does it freeze?

- Does the device enumerate as USB3.0 or USB 2.0 device?

- Please share the UART debug prints for us to check

- Which FX3 SDK version is used currently?

- Is the application UVC compliant? Which host application is being used to stream the video/image?

- Please let me know the  video resolution, bits/pixel, and FPS of the video

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

The errors cause both the application and the device to freeze – restarting the app will not work, the camera must also be restarted. On re-boot the camera correctly restarts in USB3.0 mode.

The SDK is version appears to be 1.3, but a lot of the files seem to be from around 2014. I tried re-installing it, but nothing appeared to change – is there a more recent version available?

The app isn’t UVC compliant – it was written to treat the camera as a Bulk transfer device with uncompressed 16 bit data output for astronomy. This camera has 12 megapixels but we are not trying to stream it at a high speed (typically around 4 frames per second). For reference, we have two cameras with smaller imagers (about 2 megapixels) which work much more reliably with the same app. They do crash periodically, but will often stream for 30 minutes, or more, without a problem. We get the impression that they work well, so long as the USB stream has no errors. All the cameras have 12 bits per pixel.

I will have to see about getting you the UART files.

Regards,

Terry

0 Likes

Hello Rashi,

I set up the UART and got this data stream up to the failure point. It seems that the crashes are associated with a ‘Backflow detected’ error.

UART Debug setup completed

I2C Initialisation completed

Setting IO

Setting O/P port = 50, direction = 3

Setting O/P port = 51, direction = 3

Setting I/P port = 52, direction = 2

Setting O/P port = 53, direction = 3

Setting O/P port = 54, direction = 3

Setting O/P port = 57, direction = 3

Setting O/P port = 29, direction = 1

Setting O/P port = 28, direction = 1

Setting O/P port = 27, direction = 1

Setting O/P port = 26, direction = 1

Setting O/P port = 25, direction = 1

Setting I/P port = 24, direction = 0

Setting O/P port = 49, direction = 3

Setting O/P port = 48, direction = 3

Setting O/P port = 47, direction = 3

Setting O/P port = 46, direction = 3

mode = 0X0, reset Time = 10

IMX Reset1 applied

Register table size = 267

sxWriteIMX addrH = 0X2, addrL = 0X0, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0X1, value = 0XD0

sxWriteIMX addrH = 0X2, addrL = 0X2, value = 0XAA

sxWriteIMX addrH = 0X2, addrL = 0X5, value = 0X20

sxWriteIMX addrH = 0X2, addrL = 0X8, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0XA, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0XB, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0XC, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0XD, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0XE, value = 0X3

sxWriteIMX addrH = 0X2, addrL = 0X10, value = 0XEA

sxWriteIMX addrH = 0X2, addrL = 0X11, value = 0XB

sxWriteIMX addrH = 0X2, addrL = 0X12, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X14, value = 0XF0

sxWriteIMX addrH = 0X2, addrL = 0X15, value = 0X6

sxWriteIMX addrH = 0X2, addrL = 0X16, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0X18, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0X1B, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X1C, value = 0X30

sxWriteIMX addrH = 0X2, addrL = 0X22, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0X26, value = 0XF

sxWriteIMX addrH = 0X2, addrL = 0X29, value = 0X21

sxWriteIMX addrH = 0X2, addrL = 0X36, value = 0XC0

sxWriteIMX addrH = 0X2, addrL = 0X6D, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0X70, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X71, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X72, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X74, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X75, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X76, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X79, value = 0X8

sxWriteIMX addrH = 0X2, addrL = 0X7C, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X7D, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X7E, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X80, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X81, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X82, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X89, value = 0X10

sxWriteIMX addrH = 0X2, addrL = 0X8A, value = 0X2

sxWriteIMX addrH = 0X2, addrL = 0X8B, value = 0X10

sxWriteIMX addrH = 0X2, addrL = 0X8C, value = 0X2

sxWriteIMX addrH = 0X2, addrL = 0X8D, value = 0X14

sxWriteIMX addrH = 0X2, addrL = 0X8E, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X8F, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X90, value = 0XA

sxWriteIMX addrH = 0X2, addrL = 0X94, value = 0XA

sxWriteIMX addrH = 0X2, addrL = 0X98, value = 0XA

sxWriteIMX addrH = 0X2, addrL = 0X9E, value = 0X8

sxWriteIMX addrH = 0X2, addrL = 0XA0, value = 0X6

sxWriteIMX addrH = 0X2, addrL = 0XAA, value = 0X1

sxWriteIMX addrH = 0X2, addrL = 0XAE, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0XAF, value = 0XC

sxWriteIMX addrH = 0X3, addrL = 0X65, value = 0X40

sxWriteIMX addrH = 0X3, addrL = 0X66, value = 0X0

sxWriteIMX addrH = 0X4, addrL = 0X4, value = 0X0

sxWriteIMX addrH = 0X4, addrL = 0X5, value = 0X0

sxWriteIMX addrH = 0X4, addrL = 0X12, value = 0X8

sxWriteIMX addrH = 0X4, addrL = 0X26, value = 0X3

sxWriteIMX addrH = 0X4, addrL = 0X54, value = 0X80

sxWriteIMX addrH = 0X4, addrL = 0X55, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X0, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X10, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X11, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X12, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X13, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X14, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X15, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X16, value = 0X0

sxWriteIMX addrH = 0X5, addrL = 0X17, value = 0X0

sxWriteIMX addrH = 0X7, addrL = 0X18, value = 0X78

sxWriteIMX addrH = 0X7, addrL = 0X19, value = 0XC

sxWriteIMX addrH = 0XF, addrL = 0X70, value = 0X1E

sxWriteIMX addrH = 0XF, addrL = 0X71, value = 0X0

sxWriteIMX addrH = 0XF, addrL = 0X72, value = 0X67

sxWriteIMX addrH = 0XF, addrL = 0X73, value = 0X1

sxWriteIMX addrH = 0XF, addrL = 0X74, value = 0X1E

sxWriteIMX addrH = 0XF, addrL = 0X75, value = 0X0

sxWriteIMX addrH = 0XF, addrL = 0X76, value = 0X67

sxWriteIMX addrH = 0XF, addrL = 0X77, value = 0X1

sxWriteIMX addrH = 0X12, addrL = 0X2, value = 0X20

sxWriteIMX addrH = 0X12, addrL = 0X3, value = 0X55

sxWriteIMX addrH = 0X12, addrL = 0X17, value = 0X3

sxWriteIMX addrH = 0X12, addrL = 0X1E, value = 0X3

sxWriteIMX addrH = 0X12, addrL = 0X3D, value = 0X24

sxWriteIMX addrH = 0X12, addrL = 0X40, value = 0X9

sxWriteIMX addrH = 0X12, addrL = 0X41, value = 0X6A

sxWriteIMX addrH = 0X12, addrL = 0X4A, value = 0XC0

sxWriteIMX addrH = 0X12, addrL = 0X56, value = 0X18

sxWriteIMX addrH = 0X12, addrL = 0X94, value = 0X6

sxWriteIMX addrH = 0X2, addrL = 0X36, value = 0XC0

sxWriteIMX addrH = 0X2, addrL = 0XB, value = 0X0

Writing USB2 Values

sxWriteIMX addrH = 0X2, addrL = 0X14, value = 0XF0

sxWriteIMX addrH = 0X2, addrL = 0X15, value = 0X6

EP0-Exit

EP0-Cmd, Type = 0XC0, Command = 0XA0

wValue = 0XE600, wIndex = 0X0, wLength = 0X1

0 Likes

Hello Terry,

Please confirm that the firmware is built with the latest SDK version i.e. SDK 1.3.4 https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit.​ You can check the build variable of the project to confirm if the firmware is built with SDK 1.3.4 i.e. 1_3_4 ( Project Properties>  C/C++ Build> Build Variable)

- Please confirm if the firmware is based on the AN75779 firmware https://www.cypress.com/documentation/application-notes/an75779-how-implement-image-sensor-interface...

It seems that the crashes are associated with a ‘Backflow detected’ error.

>> In the traces shared, I didn't see this print. Please let me know if this error is handled in the firmware?

Is it possible to share the firmware file (without the sensor settings)

Can you please let me know the bandwidth of the video stream?

It can be calculated as  H_active* V_Active*bits/pixel*fps

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

I think that the UART text was truncated – here is the significant part -

Initialising GPIF

sxWriteIMX addrH = 0X2, addrL = 0XA, value = 0X0

sxWriteIMX addrH = 0X2, addrL = 0X0, value = 0X0

sxWriteIMX addrH = 0X4, addrL = 0X4, value = 0X0

Go-Stream

Backflow detected, cbArg = 0X1006, framesSent = 30

With regard to your other questions.

1) The installation is 1.3.4 but the project properties that you indicated has the variable ‘greyed out’. Does this indicate a problem?

2) I’m happy to send you the firmware files – which files would you need?

The code is based on the AN75779 although modified for our specific application.

The current frame rate with the test pattern is such that the data stream is approximately 2.2Gb/s

Regards,

Terry

0 Likes

Hello Terry,

Backflow errors are generally detected when the DMA buffers overflow.

Please confirm if the CyU3PDmaMultiChannelCommitBuffer fails. If yes, please let me know the error code returned by the API.

Please do not use CyU3PDebugPrint in the DMA callback to print the error code instead use a global variable to save the error code returned and print the variable in the for loop of the UVCAppThread_Entry function.

1) The installation is 1.3.4 but the project properties that you indicated has the variable ‘greyed out’. Does this indicate a problem?

>> Can you please share the snippet

2) I’m happy to send you the firmware files – which files would you need?

>> Please share the uvc.c, uvc.h files

The code is based on the AN75779 although modified for our specific application.

>> Is the GPIF state machine also modified? If yes, please share the GPIF project also

What is the GPIF bus width used?

Regards,

Rashi

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

Hi Rashi,

Here are the h and c files that we are using – I hope that they help.

I will see if I can send the other info. shortly.

Regards,

Terry

0 Likes

Hello Terry,

From the files shared, I understand that the Multi AUTO DMA channel is used for streaming the video.

The backflow error generally occurs when the DMA buffer overflow i.e. when the host is slow to consume the data from the DMA buffer.

Please try increasing the DMA Buffer size to 32 KB  from 15 KBand DMA buffer count to 4 from 8. As the DMA buffer size changes the other changes also need to be done as mentioned in this KBA Configuring Buffer Sizes in AN75779 UVC Firmware – KBA90744  As this is non UVC application, the changes in probe control structure will not be applicable

To confirm the backflow error you can try including this code and check if the thread overflow is seen

if(cbType==CYU3P_PIB_INTR_ERROR)

{

    switch (CYU3P_GET_PIB_ERROR_TYPE(cbArg))

    {

        case CYU3P_PIB_ERR_THR0_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR0_WR_OVERRUN");

        break;

        case CYU3P_PIB_ERR_THR1_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR1_WR_OVERRUN");

        break;

}

}

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

Your recommendations look very helpful, but I’m editing code that was written by an engineer who is no longer with us and I’m not making much progress with these changes.

The DMA buffer size appears to be defined in line 62 of the .h file as:

// DMA buffer size used for video streaming.

#define SX_VC3_STREAM_BUF_SIZE (SXVC3_EP_BULK_VIDEO_PKTS_COUNT * SXVC3_EP_BULK_VIDEO_PKT_SIZE) /* 15360 bytes */

// Number of DMA buffers per GPIF DMA thread.

#define SX_VC3_STREAM_BUF_COUNT (8)

Can I simply define it as 32K, or is it more complicated than that (I’m sure that it is!). I also see 8 buffers already defined, but this doesn’t match your comments about increasing it to 8.

I looked at the KBA90744 note, but the functions LD_DATA_COUNT and LD_ADDR_COUNT don’t appear in our code, so I’m stuck there as well!

Separately, the CYU3P_PIB_INTR_ERROR code snippet is giving me a heap of syntax errors – do I need to add another include file to get this to compile?

Sorry to be a bit clueless with this, but it would be great if you could add the code that I need to the listing provided – many thanks!

Regards,

Terry

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

Hello Terry,

I have modified the SX_VC3_STREAM_BUF_COUNT and SX_VC3_STREAM_BUF_SIZE in the header file

Can I simply define it as 32K, or is it more complicated than that (I’m sure that it is!). I also see 8 buffers already defined, but this doesn’t match your comments about increasing it to 8.

>> I meant to decrease the DMA buffer count to 4

I looked at the KBA90744 note, but the functions LD_DATA_COUNT and LD_ADDR_COUNT don’t appear in our code, so I’m stuck there as well!

>> These parameters can be modified in the GPIF state machine (.cyfx) file. Please share the .cyfx file so that I can do the changes

Separately, the CYU3P_PIB_INTR_ERROR code snippet is giving me a heap of syntax errors – do I need to add another include file to get this to compile?

>> In the code you shared, the CYU3P_PIB_INTR_ERROR is handled in SxVc3AppPibCallback, you can modify it as below

SxVc3AppPibCallback(CyU3PPibIntrType cbType, uint16_t cbArg)

{

if(cbType==CYU3P_PIB_INTR_ERROR)

{

    switch (CYU3P_GET_PIB_ERROR_TYPE(cbArg))

    {

        case CYU3P_PIB_ERR_THR0_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR0_WR_OVERRUN");

        break;

        case CYU3P_PIB_ERR_THR1_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR1_WR_OVERRUN");

        break;

}}

Please let me know if you have any queries on this

Regards,

Rashi

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

Many thanks Rashi – I’ll give the code a try.

Here is the state machine file that you requested.

Regards,

Terry

0 Likes

Hi Rashi,

I tried the buffer size change, but anything above 30720 (double the previous size) causes the camera to fail to enumerate.

Regards,

Terry

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

Hi Rashi,

Here is the actual GPIF file that is in use – I accidentally sent the previous development version.

Regards,

Terry

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

Sorry – yet another problem – the error capture code throws up an error, as in this screen capture:

Regards,

Terry

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

Hello Terry,

I have modified the LD_DATA_COUNT and LD_ADDR_COUNT values according to this equation: 

  Count = ((producer_buffer_size)/(data_bus_width))-1

count = 30720 /3 (bytes) - 1 = 10239

- Please replace cyfxgpif2config.h (attached with this post) with the cyfxgpif2config.h file in the project and build the firmware again

counter_value.PNG

Sorry – yet another problem – the error capture code throws up an error, as in this screen capture:

>> You can add the default case at the end to avoid the warning

if(cbType==CYU3P_PIB_INTR_ERROR)

{

    switch (CYU3P_GET_PIB_ERROR_TYPE(cbArg))

    {

        case CYU3P_PIB_ERR_THR0_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR0_WR_OVERRUN");

        break;

        case CYU3P_PIB_ERR_THR1_WR_OVERRUN:

        CyU3PDebugPrint (4, "CYU3P_PIB_ERR_THR1_WR_OVERRUN");

        break;

        default:

        CyU3PDebugPrint (4, "No Error :%d\n ",CYU3P_GET_PIB_ERROR_TYPE(cbArg));

            break;

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

Some progress!

I added the ‘default’ statement and got the code to compile OK. I then tried the mods. to the GPIF and the stream buffer size, but got a very corrupt image with a rapid stream fail. Although I didn’t expect a good result, I tried setting the buffer back to the original size (leaving the GPIF unchanged) and it then gave a good image frame! It also seems to be more stable, although it’s always difficult to be certain about this. When it did fail, this is the UART output:

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

No Error

CYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUN

EP0-Exit

EP0-Cmd, Type = 0X40, Command = 0X16

wValue = 0X0, wIndex = 0X8F, wLength = 0X1

STOP_STREAMING - 143, - 148, tmo = -750

0 Likes

Hello Terry,

Please confirm that the shared UART debug prints are for the case when

DMA buffer size - 30 KB

GPIF header file - The one shared in the previous post.

Although I didn’t expect a good result, I tried setting the buffer back to the original size (leaving the GPIF unchanged) and it then gave a good image frame!

>> This is not a recommended approach. The DMA buffer size in the firmware and the Data and address counter values are related

Count = ((producer_buffer_size)/(data_bus_width))-1

count = 30720 /3 (bytes) - 1 = 10239

If yes, the CYU3P_PIB_ERR_THR0_WR_OVERRUNCYU3P_PIB_ERR_THR1_WR_OVERRUN errors are seen when the DMA Buffer is overwritten. This happens when the USB host is slow to consume the data written in the DMA buffer by the sensor.

This error can be avoided by either reducing the FPS from the sensor or this error can be recovered by the using the workaround mentioned in the KBA Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

Out of the two workarounds mentioned, we have tried increasing the DMA buffer size. The application needs to be stopped and started again for the second workaround to recover from this error

Regards,

Rashi

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

Hi Rashi,

If I use the 30720 x 4 buffer setting with the new GPIF file, I get corrupt images, as below:

This is supposed to be a single rectangle on a greyscale background, so it looks like only every other pixel is being read out.

Going back to the 15360 x 8 buffer gives a good image, but still tends to crash quickly with the overflow error. Changing the GPIF file values doesn’t appear to change things, although I have tried to make sure that the code is compiled correctly.

Regards,

Terry

0 Likes

Hi Rashi,

Do you think that the host software might be the real cause of the overflows? We use that latest Cypress USB3 driver and the software employs 16 image buffers to handle fast image updates, but perhaps something just doesn’t work rapidly enough. Any thoughts would be welcome.

Regards,

Terry

0 Likes

Hello Terry,

This is supposed to be a single rectangle on a greyscale background, so it looks like only every other pixel is being read out.

>> Can you please let me know the video line size i.e. H_active * bits/pixel

Do you think that the host software might be the real cause of the overflows?

>> The thread overrun errors are seen when we are trying to write to the already filled DMA buffers. This situation generally occurs when the USB host is not consuming the DMA buffers and the sensor is writing to it.

We use that latest Cypress USB3 driver and the software employs 16 image buffers to handle fast image updates, but perhaps something just doesn’t work rapidly enough.

>> If the host application is fast enough, we can try increasing the DMA buffer size. As we tried before, it seems there is some problem between the DMA buffer size and the video line size. Please let me know the video lines size to help you better.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

The line length is a total of 4104 x 12 bit pixels (height is 3000 lines). Two pixel values are concatenated into a 24 bit word and sent as 3 x 8 bit values to be re-assembled at the host. The most significant 8 bits of each pixel are displayed on the host screen.

As a test, I tried slowing down the P clock from 98MHz to 24.5MHz and this enabled the test pattern to run all night without any errors, so, as you say, the buffers are not being emptied quickly enough when the data is coming in at the maximum rate. A 50% reduction of the clock made it better, but overflow errors still occurred occasionally.

Many thanks for your help!

Regards,

Terry

0 Likes

Hello Terry,

The line length is a total of 4104 x 12 bit pixels (height is 3000 lines). Two pixel values are concatenated into a 24 bit word and sent as 3 x 8 bit values to be re-assembled at the host. The most significant 8 bits of each pixel are displayed on the host screen.

>> The DMA buffer size (30720 bytes) is not exactly divisible by  video line size ( 6156 bytes). Please let me know if the overrun error was seen with 30720 bytes DMA buffer and the new GPIF header file. I understand that video was not as expected but we need to know if the overrun error was seen or not.

Please let me know if the SYSCLK is configured for 403.2 MHz in the firmware by setting setSysClk400 as CyTrue when PCLK used is 98 MHz

/* Initialize the device */

    CyU3PSysClockConfig_t clockConfig;

    clockConfig.setSysClk400  = CyTrue;

    clockConfig.cpuClkDiv     = 2;

    clockConfig.dmaClkDiv     = 2;

    clockConfig.mmioClkDiv    = 2;

    clockConfig.useStandbyClk = CyFalse;

    clockConfig.clkSrc         = CY_U3P_SYS_CLK;

    status = CyU3PDeviceInit (&clockConfig);

    if (status != CY_U3P_SUCCESS)

    {

        goto handle_fatal_error;

    }

A 50% reduction of the clock made it better, but overflow errors still occurred occasionally.

>>Configure horizontal blanking of the image sensor as high as possible (to do this vertical blanking can be reduced thereby maintaining same frame rate). While doing this make sure that vertical blanking does not go below ~350 us.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

The system overran with the 30720 byte buffer setting and it did this very quickly – only 1 or 2 frames before failing. Is it important to match the line length to the buffer size? That may be possible.

I couldn’t find the system clock speed setting in the code, but adding the statements that you provided didn’t seem to change anything.

I’ll have a go at changing the H blanking to see what effect this has.

Regards,

Terry

0 Likes

Hello Terry,

The system overran with the 30720 byte buffer setting and it did this very quickly – only 1 or 2 frames before failing. Is it important to match the line length to the buffer size? That may be possible.

>>  We do not need to match the DMA buffer size and video line size. We need to check if the DMA Buffer size is not the exact multiple of video line size. And in this case it is not. so not changes are needed.

I’ll have a go at changing the H blanking to see what effect this has.

>> Increasing the H blanking should solve this error.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi (and Happy Holidays!)

Are there signals that can be generated for nearly full and nearly empty DMA buffers? We may be able to use these to control an external FIFO buffer in the FPGA.

Thanks for any suggestions!

Terry

0 Likes

Hello Terry,

Please let me know if you are using a configuration like this Camera/Sensor >> FPGA >> FX3.

Are there signals that can be generated for nearly full and nearly empty DMA buffers? We may be able to use these to control an external FIFO buffer in the FPGA.

>> Yes, we have two Flags which can be used for Flow control.  You can refer to section 8 of this App note https://www.cypress.com/file/136056/download . But for using these flags, the GPIF state machine needs to be modified.

Please let me know the video frame size which will be sent to FX3. It would be good if you could increase the H blanking time  of the video and increase the DMA buffer size. This will help in reducing the Overrun errors.

Please let me know if you are fine to use the DMA Manual channel which will be slower as compared to DMA AUTO channel. As in your current firmware DMA AUTO channel is used which is faster as compared to DMA Manual channel used in AN75779 firmware. Using DMA Manual channel can help in reducing the speed difference between the sensor and host.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

I’ve experimented with the H blanking and got the streaming to work a little better, but the blanking value does seem to be rather critical, especially when I try to capture single frames. The DMA buffer size changes don’t appear to work, as I only ever get corrupt images, so I can only assume that I’m probably doing something wrong with this change.

I’m certainly interested in trying to apply external FIFO control, as we have a FIFO in our FPGA that was intended to buffer the feed from the sensor, but is currently probably not being effective, as it does not have feedback from the DMA. Using a manual channel shouldn’t be a problem, as a slightly slower frame rate is OK. Our current frame size is 4072 x 3000, but we would need to use other sensors with the design, so will this be easily possible?

As you know, I’m no expert on the FX3 firmware, so I will need some clear guidance on how to change the way that the DMA operates with an external FIFO. Thanks!

Regards,

Terry

0 Likes

Hello Rashi,

As a follow up to your mail, I had a look at the app note for the slave FIFO control and I get the impression that it is considerably more complex than what I really need. It also uses a lot of extra control lines that I do not have available. As far as I can see, all that I need is a single output from the FX3, which switches high when the DMA is nearly empty and switches low when it is nearly full. I can then arrange the FIFO to send data to the DMA when the line is in the high state. Would this work?

Regards,

Terry

0 Likes

Hello Terry,

We can do this step by step

- We can first try to change the DMA channel to Manual and check if the issue is resolved with slow data rate.

- If this doesn't work, we can use the DMA water mark flag which will indicate when the DMA buffer is nearly full so that the data transfer can be stopped from the FPGA

Please share the complete firmware along with the GPIF state machine(.cyfx) in .zip file as I am not able to access the .7z folder that you had shared earlier

Regards,

Rashi

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

Hello Rashi,

That seems to be a great way forwards – many thanks for the help! Here is the complete FX3 code, as it currently exists, in a .zip file.

Regards,

Terry

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

Hello Terry,

Please find the attached firmware modified to change the DMA channel to Manual. You can track the changes using the the macro STREAM_MANUAL. Enabling the macro STREAM_MANUAL will enable the MANUAL DMA channel.

I have modified the DMA buffer size to 30720 (30 KB) as the data counter and address counter is configured for 10239 in the GPIF state machine.

Please build the firmware, program the FX3 and share the complete UART debug prints for me to check

Regards,

Rashi

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

Hello Rashi,

The images are not good when using the double buffer size (see below) but the UART isn’t reporting any errors (file attached). The bad image is from the firmware as you sent it, so ‘Manual stream’ is enabled and the 30720 buffer size is in operation.

Here is the good image from the old firmware with the 15360 buffers:

Can you make any deductions from this?

Regards,

Terry

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

Hello Terry,

From the UART debug prints I didn't see any failures.

Please let me know if the original problem is still seen with the MANUAL channel (30 KB DMA buffer) other than the image distortion

Can you check this configuration

DMA buffer size - 15KB

GPIF state machine : LD_COUNT/ADDR_COUNT : 5119 ((15360/3) -1) (header file attached). Please replace the header file with the one in the firmware and let me know if the original problem is seen

Regards,

Rashi

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

Hello Rashi,

Unfortunately, it seems to be much less stable. The first streaming frame looks like this -

If I reduce the P clock to one quarter of the normal speed (24 MHZ) it will run, but crashes after a few frames. The full speed UART output is attached.

Regards,

Terry

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

Hello Terry,

Can you please keep the PCLK same (original value) and DMA buffer as 15KB.

Please confirm if the STREAM_MANUAL macro is enabled.

If the macro is enabled, in the UART debug prints that you shared, I didn't see the producer and consumer counts which are printed after every frame is received which means that before 1 frame is received, the commit buffer failure occurs.

In that case, please let me know answer to this question

>>Please let me know if the original problem is still seen with the MANUAL channel (30 KB DMA buffer) other than the image distortion

Please find the attached modified firmware to print the failure code of CyU3PDmaMultiChannelCommitBuffer API

When commit buffer failure occurs with failure code 71, it can be solved using the points given in this KBA Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830

1) Increase DMA buffer size

2) Start and Stop the streaming :

AppStop: The DMA channel needs to be reset, GPIF state machine should be stopped.

AppStart: The DMA transfer needs to be started, GPIF machine should be started  //not implemented in your firmware

I have modified the firmware to add the code snippet mentioned in point 2 of the KBA

The state machine shared by you SxFX3\GPIF II Designer\ImageSensorInterface.cydsn  is different then the .header file used in the firmware (cyfxgpif2config-Fifo.h).

The current cyfxgpif2config-Fifo.h state machine uses the LD_DATA_COUNT and  LD_ADDR_COUNT is 5119. If you were using the same file

cyfxgpif2config-Fifo.h  with DMA buffer size of 30 KB then distorted images are expected.

I have modified the cyfxgpif2config-Fifo.h  with LD_DATA_COUNT and  LD_ADDR_COUNT is 10239 for 30 KB DMA buffer size. Please import the firmware attached to this post to a new workspace, build the firmware successfully and program FX3 and share the UART debug prints.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

I created a folder with the unzipped files, but the Cypress software won’t open the workspace (no files are visible). Is this caused by the files being generated on a different drive? I’m using drive Q on my machine.

Regards,

Terry

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

Hello Terry,

Please try using the attached firmware

Regards,

Rashi

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

Hello Rashi,

Thanks for the new files, but I got the previous ones to open by using the ‘Import’ function – I assume that this is OK.

I ran the new firmware at full speed (P clock 98MHz) and it ran for a short time with correct images. It stopped working after about 20 seconds and I captured the attached UART output from the last good frame to the full breakdown. I hope that this is helpful.

Regards,

Terry

0 Likes
lock attach
Attachments are accessible only for community members.
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Terry,

Please let me know if the device recovers after the errors i.e. the streaming restarts (on the host application)  or it completely stops (black screen or frozen). From the UART debug prints I can see that the application is re initialized DMARESET: APP re initialized = 0 which means the application (streaming) is restarted after the commit buffer failure.

Please let me know if you get the debug prints after the failure.

I have added few more debug prints to the firmware attached. Please let me know the results (UART debug print) with this firmware

 

 

 

Regards,
Rashi
0 Likes