As you mentioned that CyU3PDebugPrint API is called at many instances in the firmware, please let me know if CyU3PDebugPrint is called inside the DMA callback or any other callbacks
My firmware prints lots of debug output via UART and hangs after a while.
>> Please let me know approx how many bytes are written using UART debug prints from one thread and how many such threads are running in your firmware.
>> Also, let me know the return status of CyU3PDebugPrint when the UART prints hang.
CyU3PDebugPrint is called in the main thread, the DMA callback, the PIB callback and the UIB callback (mainly to report errors).
The output is approximately less than 40 lines or 2kb per second
If glDebugLock is locked, CyU3PDebugPrint won't return.
I logged previous return values in an array: 0 (CY_U3P_SUCCESS), 19 (CY_U3P_ERROR_INVALID_CALLER) and 29 (CY_U3P_ERROR_MUTEX_FAILURE).
CY_U3P_SUCCESS and CY_U3P_ERROR_INVALID_CALLER can be returned by CyU3PDebugPrint.
But CY_U3P_ERROR_MUTEX_FAILURE does not appear in that function, so it must have been returned by CyU3PDmaChannelCommitBuffer or CyU3PDmaChannelGetBuffer. This means that "return stat" in line 18 (originally line 548) was executed and that glDebugLock was not released.
We do not recommend to call CyU3PDebugPrint inside the callback function.
As per section 188.8.131.52 of FX3 API guide (SDK), no blocking calls should be made from the DMA callback function
The CyU3PDebugPrint() API can encounter a failure when invoked from a callback function. You can check the return value of the API by setting it to a global variable and reading it in the thread main loop.
Please let me know if the problem still occurs when the CyU3PDebugPrint is removed from the callback function. Meanwhile, I will try to reproduce the issue at my end.