Manual Out Endpoint works for a while, then gives MUTEX_FAILURE

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

cross mob
ThAl_4704151
Level 4
Level 4
25 sign-ins 25 replies posted 10 replies posted

I'm creating a new question because it turned out that my old one didn't have the right answer after all, and it's locked now so I can't change it.

I have 4 endpoints that are set up as auto channels, with DMA notifications. They work great. 

I tried to set up a fifth endpoint to do some logging from the DMA callback via a manual out endpoint. I've determined that it is seeing the new data every time a buffer is filled from one of those endpoints, and it's output works for 39 entries that I can see on the host, but then it stops working. Every time I try to call CyU3PDmaChannelGetBuffer after that, it fails with a CY_U3P_ERROR_MUTEX_FAILURE.

0 Likes
1 Solution

While I was checking stuff to answer your questions, I was able to figure it out.

The way I have it set up, I have 4 "real" endpoints that our production application uses to communicate with and 8051 microcontroller. 2 is for buffered input, 4 for immediate input, 6 for output, and 8 for a strange debugging measure that never really worked properly, but such is the way of legacy code.

 The project as a whole is to replace the old SX2 chip with the FX3, so I added a fifth endpoint to help in debugging communication problems we've been having. Basically, all it does is respond to the DMA callback when data is produced, and send that on through the debug port. There's a little metadata I add, but the idea is that this way, I can log all the data going through the FX3 without consuming it, so I don't interfere with the production app running on the host PC.

You mention UART, but this whole effort is essentially because the guy who laid out the board for me didn't think UART was important, and didn't give me access to it.

I mentioned that it was configured as a manual out instead of using the function that sets it up for debugging output because the debugging output function interprets 0s as null terminators, and my data often contains 0s. I could convert it to an ascii string of hex digits to get around that, but I'm already doubling the throughput with the debugging output, and I didn't want to double it again by using two characters for every byte of data.

Anyway, thing I figured out was that buffers 6 and 8 were filling up, so the debug endpoint really wasn't getting any more data. I had added a call to read in those endpoints but I used a & when I should have used and |, so I was trying to open the wrong endpoint, and thus those buffers were never getting emptied.

No idea why I saw the mutex error message again. Maybe I was running old code. Maybe my debugging interfered with something. If the problem that I found was the whole thing, I should never have hit a breakpoint there in the first place. That concerns me a little, but it seems to be working again, at least for now.

View solution in original post

0 Likes
3 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please share the latest source codes with us for checking. Also, please share the UART debug logs when the issue is seen.

In addition to this, please let us know if this "39 entries" is always constant or does it vary? Can you also elaborate the following line in your description:
"I tried to set up a fifth endpoint to do some logging from the DMA callback via a manual out endpoint."

Best Regards,
Jayakrishna
0 Likes

While I was checking stuff to answer your questions, I was able to figure it out.

The way I have it set up, I have 4 "real" endpoints that our production application uses to communicate with and 8051 microcontroller. 2 is for buffered input, 4 for immediate input, 6 for output, and 8 for a strange debugging measure that never really worked properly, but such is the way of legacy code.

 The project as a whole is to replace the old SX2 chip with the FX3, so I added a fifth endpoint to help in debugging communication problems we've been having. Basically, all it does is respond to the DMA callback when data is produced, and send that on through the debug port. There's a little metadata I add, but the idea is that this way, I can log all the data going through the FX3 without consuming it, so I don't interfere with the production app running on the host PC.

You mention UART, but this whole effort is essentially because the guy who laid out the board for me didn't think UART was important, and didn't give me access to it.

I mentioned that it was configured as a manual out instead of using the function that sets it up for debugging output because the debugging output function interprets 0s as null terminators, and my data often contains 0s. I could convert it to an ascii string of hex digits to get around that, but I'm already doubling the throughput with the debugging output, and I didn't want to double it again by using two characters for every byte of data.

Anyway, thing I figured out was that buffers 6 and 8 were filling up, so the debug endpoint really wasn't getting any more data. I had added a call to read in those endpoints but I used a & when I should have used and |, so I was trying to open the wrong endpoint, and thus those buffers were never getting emptied.

No idea why I saw the mutex error message again. Maybe I was running old code. Maybe my debugging interfered with something. If the problem that I found was the whole thing, I should never have hit a breakpoint there in the first place. That concerns me a little, but it seems to be working again, at least for now.

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

We are glad to hear that the issue is resolved. We also recommend you to not use any kind of blocking calls in any of the callback functions (Eg: DMA callback, Timer callback, callbacks invoked by USB driver). You can use the approach suggested by frank in the thread that was created before. The link to the thread is given below:

https://community.infineon.com/t5/USB-superspeed-peripherals/Can-t-get-a-manual-out-endpoint-to-work...

Best Regards,
Jayakrishna
0 Likes