0
\$\begingroup\$

Another USB question here... same as last time; USB Audio on an ARM microcontroller. I have both endpoints (input and output) as isochronous/asynchronous transfers. In addition I have Timer Counter (TC) interrupts to poll for UI processes on my board.

To summarize, when I have a clean bypass (no USB involved), I get no interruptions; clean signal. Great!!! No weird out of sync issues with the I2S bus/codec; no weird blips, nothing. However, when USB Audio is enabled, things get weird. In my previous question on stackexchange, I didn't have any other UI processes going on (checking for button presses) so the USB audio was pretty clean.

How I read from codec to USB:

(1) USB Input enabled, start USB writes
(2) Write an empty buffer to USB endpoint
(3) Send USB data buffer
(4) Wait for USB write callback
(5) Completed USB write; do the following:
    (a) read next buffer from codec (I2S-DMA) and load that into USB buffers
    (b) Send next available USB buffer to endpoint
    (c) Repeat Step 4-5

Ways I have tried to poll for UI processes (button presses):

(1) USB start of frame interrupts
(2) Timer Counter interrupts 
(3) Main while loop polling

All of these cause glitches in my USB Audio writes/codec reads. I can only guess that when an interrupt happens, my codec read gets interrupted and the mcu drops some samples. However, I'm not sure why just regular polling is causing a glitch issue. In terms of interrupt priorities, my I2S-DMA and USB interrupts are highest priority whereas my TC interrupts are very very low (like the lower number).

The question (if you haven't already guessed) is: How do I get my mcu to happily read/write continuous audio from my codec to USB while polling for these other UI processes? I can only imagine I will need to do more than button presses in the future so I'm thinking this could be applicable to other mcu peripheral applications.

Sorry in advance this is an easy question or the answer is really obvious; I'm still relatively "new" to microcontrollers and USB. I can easily figure out things in the software domain now but when it comes to hardware AND software... it's a whole different story for me. Any articles I can read without bothering anyone would also be appreciated. Thanks!

EDIT - Answer: So I know there was code here before but through posting it... I realized my mistake. In my button processing code, I had reads/writes being done to mcu's flash as well. When I removed those parts of the code, I didn't hear glitches anymore. Ugh! Sorry for bothering everyone, such a user error on my end. The reads/writes to flash were just there to save certain settings in case the user was to accidentally disconnect power.

\$\endgroup\$
  • \$\begingroup\$ Well, when do you "have time" to poll? Perhaps set the polling routine as an interrupt, and call it quickly once every-so-often when you know there is enough time to service it. \$\endgroup\$ – rdtsc Jul 25 '17 at 0:19
  • \$\begingroup\$ @rdtsc Good point. I guess there would be time right after I send a USB packet as it waits for the completion callback. I'll think about it more but thanks for the advice! \$\endgroup\$ – yun Jul 25 '17 at 2:47
  • \$\begingroup\$ Without seeing the actual code we can only guess what the problem is. Polling for button presses in main should not affect interrupt driven processes. Can you show us how you did this? \$\endgroup\$ – Bruce Abbott Jul 25 '17 at 19:45
  • \$\begingroup\$ @BruceAbbott Yea I can post some of the code. I just figured it wouldn't help out too much because this seems to be more of a "what approach should I take" rather than "what's wrong with my code". Obviously it could still be the latter. \$\endgroup\$ – yun Jul 25 '17 at 19:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.