unexpected values of CX3 machine state

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

cross mob
leda_289486
Level 5
Level 5
10 sign-ins 5 sign-ins 100 replies posted

Hi,

we have been monitoring CX3 value of its state machine in our firmware.

for this usage , we use CyU3PGpifGetSMState(&SMState); function from api.

Some SMState value are outside the 0-15 range. We have 131 and 132 values as SMState : is this normal ?

Thank you for your help,

Best Regards,

0 Likes
1 Solution
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

This is because of the presence of mirror states in the CX3 state machine. Please refer section 4.5.1 " Mirror states" of gpif2_designer_userguide for more details about mirror states.

View solution in original post

0 Likes
23 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

Can you please post the snippet where exactly you have called CyU3PGpifGetSMState API in your code?

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

Sure,

I've added the state check to the mipi monitoring thread.

here is included the snippet.

Best Regards

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

This happens when there are mirror states in the design.

Please refer section 4.5 of GPIF Designer User Guide.

Attached for quick reference.

0 Likes

Hi srdr,

thank you for this document and precision.

I'd like to precise some point on CX3 :

We can have data flux streaming during hours correctly at more the 1 Gbit/s typical. However, sometimes we observed a 0xC0000001 IRP return from camera in driver and streaming is stopped (no more answer on video endpoint because no more answer from CX3). Have you a code snippet for firmware after this particular situation ? others endpoints such are EP0 are answering correctly.

We have also sometimes another issue, related to previous one. After stopping flux completly because of previous issue, we restart and then frames are corrupted as if the dma buffers run with bad socket : Is there a way to reset socket and buffers of CX3 between two frames to restart always on same socket and a way to "clean" all buffers (producers+consumer)  between two frames after all dma+Usb transfers are done (and of course before new data incoming from sensor) ?

Thank you for your help,

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

Lebrun,

Can you please check the section IV USB Data Corruption (Page #8) in FX3_SDK_TroubleShooting_Guide.PDF (attached for reference) and implement the work around?

Refer GpifToUsb example firmware for the implementation.

Put a flag in USBEP_SS_RESET_EVT and print it in the infinite for loop.

I am trying to know whether there is SS_RESET_EVT in your case. If yes, we can reset the endpioints and DMA channel over a  Clear Feature request.

0 Likes

Hi srdr,

this implementation doesn't change the behavior : it is never triggered so I guess this mean the usb 3 signal is rather correct.

Here is the situation : for some reason it happens that there is no more transfers because consumer socket is stuck whereas producer is present but of course buffers are very quickly full.

Is there a way to clean correctly all buffers from producer and consumer point of view so that transfers can happen again without stopping from driver ?

I think the problem is really in firmware part because I see the IRP request from driver that is not satisfied and no other transfer after that is satisfied.

Again this is quite rare but painful. For example, streaming @ 1.7 Gbits/s all week-end with no error.

Best Regards

0 Likes

Hi srdr,

I've tried everything to restart flux when driver receives an 0xC0000001 answer (and nothing else after) from CX3 to an IRP. We have a 4 producer buffers configuration (2 sockets, 2 buffers each). Each time we aren't able to restart consumer socket correct handling and the only way is to stop/restart flux from driver side which is not a correct solution.

In firmware, we are detecting correctly the situation after few ms. We are trying to reset the sockets to restart flux but if this seems to work for producer sockets this never works for consumer socket : what can prevent the consumer to restart on firmware side ?

Thank you for your help.

Best Regards,

0 Likes

Hi srdr,

I also have implemented the usb log debug feature. When streaming normal, I've got no message at all.

Once it is stalled i have :

DEBUG LOG : AF

DEBUG LOG : AF

DEBUG LOG : AB

DEBUG LOG : AB

Hope this can help.

Best Regards,

0 Likes

I confirm the debug log behavior.

Each time streaming is stopped, I've got these messages.

Sometimes there is only one DEBUG LOG : AF but always DEBUG LOG AF and then DEBUG LOG AB.

Is there a document to explain what this means exactly ?

Thank you for your help,

Best Regards,

0 Likes

Hi,

The log 0xAF corresponds to CYU3P_USB_LOG_EP_UNDERRUN and 0xAB corresponds to CYU3P_USB_LOG_EPM_RESET.

EP underruns happen when the DMA channel is suddenly reset just when the PC asks for data. The USB controller will then receive conflicting information on buffer availability and an underrun is reported.

  • Can you check if you do any DMA channel resets in your code (other than the clear_feature reset)? Also, do you see this underrun reported in USB 2 only or in USB 3 too?

  • Can you please share your firmware?

In order to over come the Underrun error kindly follow the following code .

When you get a UNDERRUN in the call back , set a flag in the call back . In your main thread check for this flag and if the flag is set the reset the end point memory , DMA channel and starting the transfer again . The following line of code does the same .

CyU3PUsbSetEpNak(ep,1); // NAK the USB transfers until your endpoint memory is ready to recive

CyU3PDmaChannelReset(&gDmaCh); // Reset the DMA buffer to reset the pointer

CyU3PUsbGetEpSeqNum(ep,&seq); // Continue with the Old sequence number

CyU3PUsbResetEndpointMemories() // This API is used to reset reset and re-initialize the memory block, so that USB data transfers can resume.

CyU3PUsbSetEpSeqNum(ep,seq);

CyU3PDmaChannelSetXfer(&gDmaCht,0); // Start the transfer again

CyU3PUsbSetEpNak(ep,0); // Remove the NAK to start USB transfers again.

Let us know if you are still facing any issue.

0 Likes

Hi,

thank you for this information.

For the first point, I've logged with DebugPrint every dmareset places. It is not called while this condition is triggered.

I can send parts of firmware but not all.

I've included the flag detection while underrun comes. I include your code, check and tell the results.

thank you for your help,

Best regards,

0 Likes

Hi,

I confirm that firmware doesn't call dmaMultiChannelReset while streaming. By the way it is a multichannel many_to_one configuration, so I used the corresponding function ("multi") for SetXfer and channel reset.

But the issue is still present : the callback is triggered with an CY_U3P_USB_EVENT_EP_UNDERRUN event from endpoint 0x83 but the code doesn't "unblock" the situation : no transfer after.

Thank you for you help

Best Regards,

0 Likes

Hi

I forgot to tell that camera has a high data rate and is working on usb 3 port only.

For now the flag underrun is effectively set, the processing is done outside the callback function but consumer socket doesn't restart. From driver part, the driver receives nothing once underrun condition has been triggered.

I use your code with Multi in names tag for SetXfer et dma reset.

I also set a debug condition at each FrameValid : the message is correctly displayed after your snippet code has been ran, which means I guess that sensor is delivering data correctly and that producers sockets are ok.

Thank you for your help,

Best Regards

0 Likes

Hi keaj,

Here is some additionnal information about the current behavior.

we have a buffersize of 49152 bytes and PC driver is asking (16*49152) bytes at each IRP. So during frame transfer there are mostly C0000 (16*49152) transfers size + one transfer smaller due to wrapup functions at end of frame and because it is not possible to reach multiple of 49152 for a complete frame transfer size.

When overrun callback is triggered, the number of data transferred in last IRP packet (seen through an usb3 analyzer) is also a multiple of 49152 size. For example, at last transfer stop, the last packet has a size of 0x84000 bytes (11*49152) instead of 16*49152. For me this means the error comes from the fact there are no more data coming from gpif : thus it cannot restart through usb functions only ?

Is this correct and is there a way to confirm (and of course correct) this through gpif functions ?

I must say that I log the FV of sensor through a printout debug and even after the streaming is stopped, the FV printout is still present : so data seem to be still delivered by sensor when this issue is triggered.

Thank you for your help,

Best Regards,

0 Likes

extra information :

we use a 24 bits GPIF and we a thread that monitors the mipi error. Mipi error are never present during normal streaming as well as "stopped" stream. Counter stays at 0.

Best Regards,

0 Likes

Hi

I still don't understand why the process is not restarting. I've included your code as you told me, check the result for each function. No error returned, everything is CY_U3P_SUCCESS but stream doesn't restart.

I've also tried to add a MipicsiReset (soft_reset) among your code but again, return code is success and nothing restarts after.

I've checked out through an analyzer that nothing is sent on usb after your code is executed whereas the FV are present.

So, it looks as if the data where not transferred anymore either from gpif to socket producer or from producer to consumer, I don't know.

Is there any way to check these possibilities ?

Thank you for your help,

Best Regards,

0 Likes

hi keaj,

what is the status of CyU3PUsbEnableEPPrefetch function now with 1.3.4 sdk ? Could it be a solution for correcting the issue ?

Should I compile back to 1.3.3 to have this taken into account ?

Thank you for your help

Best Regards

0 Likes

Hi

I've tried to use CyU3PUsbEnableEPPrefetch to fix issue but it seems to have no effect. is this api function still relevant for 1.3.4 ? I read that it is not used anymore with this sdk version.

Best Regards,

0 Likes

Hi

Have FlushEP or ResetEP a utility here ?

Again no change of behavior.

Best Regards

0 Likes

You can try the following in your case.

Set a timer with an appropriate time period (based on your frame rate).

Start the timer in the application start (CyCx3AppStart).

Stop and Modify the timer in the producer event of DMA call back for a partial buffer and start it again.

The timer should be set to initial value if the timer does not expire.

If the timer expires, in the Timer callback, the CX3_DMA_RESET_EVENT event will be set.

In the CX3_DMA_RESET_EVENT, stop the application and start it again.

Please refer AN75779 example firmware for this implementation.

0 Likes

Hi srdr,

thank you for this information, we'll try to proceed this way with AN75779 implementation.

Best regards,

0 Likes

here is the snippet code form USBBulkSourceSink example.

best regards

void DisplayLog(void)

{

    /* Compare the current USB driver log index against the previous value. */

if (gl_UsbLogBuffer == NULL)

return;

    tmp1 = CyU3PUsbGetEventLogIndex ();

    if (tmp1 != prevUsbLogIndex)

    {

        tmp2 = prevUsbLogIndex;

        while (tmp2 != tmp1)

        {

            CyU3PDebugPrint (4, "DEBUG LOG: %x\r\n", gl_UsbLogBuffer[tmp2]);

            tmp2++;

            if (tmp2 == CYFX_USBLOG_SIZE)

                tmp2 = 0;

        }

    }

    /* Store the current log index. */

    prevUsbLogIndex = tmp1;

}

0 Likes
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

This is because of the presence of mirror states in the CX3 state machine. Please refer section 4.5.1 " Mirror states" of gpif2_designer_userguide for more details about mirror states.

0 Likes