CX3 SDK lib : CyU3PUsbSendEP0Data / CyU3PUsbGetEP0Data / CyU3PDebugPrint

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

cross mob
Anonymous
Not applicable

Hi,

   

I am using sdk CX3 SDK version 1.3.3

   

[1] I am encountering irregular things wrt to the CyU3PUsbSendEP0Data / CyU3PUsbGetEP0Data functions.

   

The first arguement of both of these is suppose to be a size in bytes according to the info in cyu3usb.h, yet I encounter several instances of CyU3PUsbGetEP0Data calls which seem incorrect in the example code (both in the Cypress SDK as in de Econ devkits democode). Most of the time it seems the first argument of the CyU3PUsbGetEP0Data  is in bits but even then it sometimes does not make sense.

   

A nice example is eg in Cx3UvcOV5640\cycx3_uvc.c line 1034:

   

       status = CyU3PUsbGetEP0Data(16, &glStillReq, &readCount);

   

(with "static uint8_t  glStillReq = 0; " ).

   

Even if the argument is in bits which the 16 seems to suggest, this still looks like a memory corruption because glStillReq is only 8 bits.

   

[2] Is  would like to have more details about CyU3PDebugPrint, is this function thread safe ? Can it be called from interrupt level ?

   

Als the documentation of this function is plain wrong: " This function can be used by the application code to log free form message strings, and causes the output message to be written to the UART immediately."

   

As become apparent by the other functions, it in fact does not immediately outputs the log message but it is placed in a buffer.

   

How big is this buffer ? Is is statically or dynamically allocated ?

   

(For some reason i get corrupted uart output from a certain point onwards after modifying the code for my own sensor)

   

[3] General question

   

Is it possible to obtain sources of parts of the SDK ? I understand the sensor and threadx code cannot be released, but it would help a lot if I could dig into the rest to find out the answer to these questions on my own and to debug stuff that is going on. Which threads are running in the system with what parameters ? How is the thread safety of all these functions ? Etc etc.

   

 

   

[4] Last remark about the code, in cyfxtx.c:

   

void *CyU3PMemAlloc (       uint32_t size)

   

...

   

    /* Cannot wait in interrupt context */
    if (CyU3PThreadIdentify ())
    {
        status = CyU3PByteAlloc (&glMemBytePool, (void **)&ret_p, size, CY_U3P_MEM_ALLOC_TIMEOUT);
    }
    else
    {
        status = CyU3PByteAlloc (&glMemBytePool, (void **)&ret_p, size, CYU3P_NO_WAIT);
    }

   

...

   

 

   

threadx memory allocation functions can not be called from interrupt context (and most malloc functions cannot), that is not not what the last argument of tx_byte_allocate is for. So another thing i wanted to check in the sources is that this is never done.

   

 

   

Regards,

   

Bram

0 Likes
5 Replies
Anonymous
Not applicable

1] The first argument of CyU3PUsbGetEP0Data is in bytes. So, if you write 16, it means 16 * 1 byte. What is the unexpected behavior you observe. Please let me know how do we re-create it here

   

2] We suggest that you do not use CyU3PDebugPrint in callback functions. You can find the source of this function in the FX3 SDK where you can check how exactly we have implemented this function.  You need to extract the fx3_sdk_1_3_3_src.zip file available here  C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware Then check the cyu3debug.c file which is available here fx3_sdk_1_3_3_src\sdk\firmware\src\system

   

3] Refer bullet 2. We have provided you the source of our libraries here. Please check and let us know if you have questions

0 Likes
Anonymous
Not applicable

1]  I did not recreate anything so far, i just looked at the code in the examples directory of the SDK and it is wrong unless i am really missing something obvious. Maybe the memory corruption remains undetected or is not triggered in actual use because the CyU3PUsbGetEP0Data is just returning a limited number of bytes, but the fact that it is passed that it could return up to 16 bytes into a variable that is only 1 byte is incorrect in any case.

   

The example i was referring to is in :

   

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\cx3_examples\cycx3_uvc_ov5640\cycx3_uvc.c, line 1034

   

(this is code that is only active with STILL_CAPTURE_ENABLE so that is another reason maybe it is not triggered)

   

(I originally ran into the question looking at the code for the econ denebola CX3 devboard, where they also do it several times in the code but i assume that is not under your control)

   

2] & 3] Thanks a lot !! I have recompiled my project with the sources so i can figure out what the cause is of my corrupted uart output. (I have a lot of trouble with debugging via Segger JLINK but i will create a dedicated topic for that)

0 Likes
Anonymous
Not applicable

Remark about cyu3debug.c, function CyU3PDebugPrint

   

It has:

   

<...>

   

    if (glDebugBufOffset)
    {
        stat = CyU3PDmaChannelCommitBuffer (&glDebugChanHandle, CY_U3P_DEBUG_DMA_BUFFER_SIZE, 0);

   

This looks like a potential candidate for corrupted output on the uart, because the full buffer size is passed as an argument while only part of the buffer is filled in ?

   

( I do not think it is the cause of my uart corruption as i do not think i have a scenario where glDebugBufOffset is nonzero)

0 Likes
Anonymous
Not applicable

I see that you have mentioned that you have recompiled your project with the source.  In that you can you try by using Discard buffer instead of commit buffer to see if that is the real trouble. 

   

 if (glDebugBufOffset)
    {
        stat =  CyU3PDmaChannelDiscardBuffer ( CyU3PDmaChannel ∗ handle );

   

This will discard the pending logs. If after doing this, you do not get any problem with the debug messages, then it makes sense that this is the cause of the problem.
Although I do not think that this should cause any problem, but please do try and let me know what your observe. Once you are able to recreate the issue, please do provide us your firmware and steps to test, so that we can look into what exactly is happening. 

0 Likes
Anonymous
Not applicable

Replacing it by a discard does not fix the problem , so the 'corruption problem' has a different cause.

   

Is seems to be timing related, if i put a breakpoint after the offending debug print statement to investigate the contents of the buffer the print comes out fine. So this would indicate that something that happens after that point manages to corrupt the buffer or the dma transfer. Unfortunately due to a very unstable debug JTAG connection it is very difficult to make progress using the debugger.

   

One other thing i saw that is that I get a few corrupted prints using release builds after which it continues again correctly, but if i use a debug build it just halts at the place the release build would give corrupted output.

   

Release output:

   

...

   

[30:UVC_app_thread.0]CyU3PTimerCreate

   

[30:UVC_app_thread.0]After CyU3PTimerCreate

   

[30:UVC_app_thread.0]Watermark 5620 of 6144

   

[30:UVC_app_thread.0]Firmware Version: 1.3.133.309

   

[30:Õ¨

   

U??ÁÁQ¡É}¹ÑÉåéªe5ê

   

õ)ªQP¢5EjjJÂÅ??j¤´5Òªe5ê

   

Í2??µJ¹ÑÉÉÕÁÑéj±±½      Á}????¹êUÍUY

   

j¤ü[04_UIB_THREAD.0]bRType = 0xA1, bRequest = 0x86, wValue = 0x400, wIndex = 0x100, wLength= 0x1

   

[04_UIB_THREAD.0]bRType = 0xA1, bRequest = 0x82, wValue = 0x400, wIndex = 0x100, wLength= 0x4

   

[04_UIB_THREAD.0]bRType = 0xA1, bRequest = 0x83, wValue = 0x400, wIndex = 0x100, wLength= 0x4

   

[04_UIB_THREAD.0]bRType = 0xA1, bRequest = 0x84, wValue = 0x400, wIndex = 0x100, wLength= 0x4

   

...

   

Debug output:

   

[30:UVC_app_thread.0]CyU3PTimerCreate

   

[30:UVC_app_thread.0]After CyU3PTimerCreate

   

[30:UVC_app_thread.0]Watermark 5468 of 6144

   

[30:UVC_app_thread.0]Firmware Version: 1.3.133.309

   

[30:

   

(halts here)

   

So maybe the debug build is checking stuff and notices something is wrong. Still need to look into what exactly the debug build does differently but if you have any tips let me know 🙂

0 Likes