Help Debugging USB Audio Code on Custom Board

[GeorgeIoak]

We have a design that closely follows the USB Audio design. I'm able to enumerate the board on the PC/MAC and I can witness a LRCLK at startup. Most of the time the LRCLK only runs for a short bit but then stops however the board stays enumerated. If I play some music while in debug I can see the DAC_DATA has some data for a brief time, maybe ~40ms, but then it stops and the code stops with a "Memory access exception error" in decouple.xc.

This is very repeatable with my board but at this point I'm not sure what to look for that caused this error. I captured the registers and some variables which I'll attach to this post and I would really appreciate it someone could give me some pointers on what to do next to try and determine what this causing this error/problem with our design.

I'm not sure if this is because I'm in debug mode but notice on the one screen shot the variable p_i2s_dac is showing an error of "Target request failed: A syntax error in expression, near '.0'

I have not modified the code at all and I have verified that this runs on the eval board so there is something "wrong" but I've gone through the hardware 100 times and can't find anything!

Thanks in Advance,
George

[bearcat]

Hang in there, I have found the XMOS USB audio design and firmware quite good.

I noticed you changed what is a constant in the original firmware NUM_USB_CHAN_OUT to a global variable (or I have an out of date version of firmware). You need to look at the value of that variable as it is probably out of range or something.

What you MAY want to try is an older version of the firmware first, like 1.7 or 1.71. These were released before the influences of the multi-channel design came into the stereo firmware. They are MUCH less complex than the current releases and easier to work with and understand.

Take that back, I don't know which design you are related to, the stereo or multi-channel. If stereo the above applies.

Having your board enumerate and send some data out means alot of it is working!

[GeorgeIoak]

Hi and thanks for the reply. We are only going for stereo at the moment and are using a DAC, not a CODEC, so only output required. I only have the most recent source code, by chance could you possibly compile a version which only takes into account stereo operation and doesn't use the SPDIF or ADC?

I didn't modify any code so possibly I did something wrong when I tried to watch some variables? This is my first time trying to debug XMOS code and I'm jumping in head first unfortunately!!

[lilltroll]

Do you only have the problem during debug-mode? What about release !?

Have you changed the Optimization level in debug-mode to (O3) ?

(It's easy to get starved out of time here)

[GeorgeIoak]

Oh no, I get this problem with the compiled code right off the web site. I initially was just looking at whether the board would enumerate or not and thinking if it enumerated things would be OK, boy was I wrong! What I first noticed was that if I go into properties of the XMOS device and go to configure (on a Win7 OS) and play the test tone the tone will start to play but then an error pops up that said it couldn't play.

Where do I set the debug level to O3?

I've noticed I've got some ripple on the 1.0V rail and am working on trying to clean that up. I've monitored the reset line to make sure it wasn't causing the chip to reset and I don't see that happening but I wonder what happens inside the L1 if it sees say 1.1V?

How can I narrow down why the code is always stopping at this point? Right now I'm "too dumb" to understand what the code is doing at this point to cause it to stop or even why it stopped. Memory Access error doesn't tell me too much..

[lilltroll]

Where do I set the debug level to O3?

In Project->Properties->X/XC Build -> Settings (and it's g3 for debug mode)

But for the Audio code the Makefile is used which can be found in the Project Explorer.
I think you should choose:
¨
File -> Import -> Existing projects ... -> Select archive file


But maybe you should explore the voltage on the rails first.

[GeorgeIoak]

Well I've got the ripple on the 1.0V rail down to 50mV so I don't think that is a concern or issue. I have a 3rd board built now and it is stopping at the exact same spot as the other boards which I guess at this point I'll take a consistent failure as something good.

I still need someone's help though to maybe strip the code down to the basics so I have less unknowns.

[bearcat]

Well, that's now the fifth time I lost my response to a post. I keep forgetting to copy it to the clipboard first in case it screws up.

You will want to pull up the dissassebly window so you can see the assembler instruction that caused the error. Also you will need to use this and the register explorer to determine the current value of a variable as they can be optimized to a register and not be shown.

I have not found the 1V rail to be over sensative to ripple.

I mention using version 1 software first, as it is much less complex and easier to debug. Looks like you would have to contact them to get it as it's not available for download. Then could move to version 2.

If you design is similiar, you would have to look at it from the circuit level.

[GeorgeIoak]

Well it's good to hear from someone else about the 1V rail but I think I have that dialed in now. I opened up the disassembly window and copied the contents here. I assume that the first line is the statement that code stopped at?

0x00012812 <handle_audio_request+570>: ldw (2rus) r1, r9[0x0]
0x00012814 <handle_audio_request+572>: add (2rus) r8, r9, 0x4
0x00012816 <handle_audio_request+574>: stw (lru6) r8, dp[0x81a]
0x0001281a <handle_audio_request+578>: bu (u6) -0x15
0x0001281c <handle_audio_request+580>: ldw (lru6) r9, dp[0x81a]
0x00012820 <handle_audio_request+584>: ldw (2rus) r1, r9[0x0]
0x00012822 <handle_audio_request+586>: stw (lru6) r1, dp[0x810]
0x00012826 <handle_audio_request+590>: add (2rus) r1, r9, 0x4
0x00012828 <handle_audio_request+592>: stw (lru6) r1, dp[0x81a]
0x0001282c <handle_audio_request+596>: ldw (lru6) r1, dp[0x810]
0x00012830 <handle_audio_request+600>: shl (2rus) r1, r1, 0x8
0x00012832 <handle_audio_request+602>: bu (u6) -0x24
0x00012834 <handle_audio_request+604>: ldw (lru6) r1, dp[0x810]
0x00012838 <handle_audio_request+608>: shr (2rus) r1, r1, 0x10
0x0001283a <handle_audio_request+610>: ldw (lru6) r9, dp[0x81a]
0x0001283e <handle_audio_request+614>: ldw (2rus) r10, r9[0x0]
0x00012840 <handle_audio_request+616>: stw (lru6) r10, dp[0x810]
0x00012844 <handle_audio_request+620>: add (2rus) r9, r9, 0x4
0x00012846 <handle_audio_request+622>: stw (lru6) r9, dp[0x81a]
0x0001284a <handle_audio_request+626>: ldw (lru6) r9, dp[0x810]
0x0001284e <handle_audio_request+630>: shl (2rus) r9, r9, 0x10
0x00012850 <handle_audio_request+632>: or (3r) r1, r1, r9
0x00012852 <handle_audio_request+634>: bu (u6) -0x34
0x00012854 <handle_audio_request+636>: ldw (lru6) r1, dp[0x810]
0x00012858 <handle_audio_request+640>: shr (2rus) r1, r1, 0x8
0x0001285a <handle_audio_request+642>: ldw (lru6) r9, dp[0x81a]
0x0001285e <handle_audio_request+646>: ldw (2rus) r10, r9[0x0]
0x00012860 <handle_audio_request+648>: stw (lru6) r10, dp[0x810]
0x00012864 <handle_audio_request+652>: add (2rus) r9, r9, 0x4
0x00012866 <handle_audio_request+654>: stw (lru6) r9, dp[0x81a]
0x0001286a <handle_audio_request+658>: ldw (lru6) r9, dp[0x810]
0x0001286e <handle_audio_request+662>: shl (2rus) r9, r9, 0x18
0x00012870 <handle_audio_request+664>: or (3r) r1, r1, r9
0x00012872 <handle_audio_request+666>: bu (lu6) -0x45

And here's the registers:

Main
r0 5122
r1 0
r2 3
r3 2
r4 2
r5 0
r6 0
r7 2
r8 1
r9 131072
r10 -536870912
r11 -256
cp 98228
dp 98864
sp 103028
lr 76984
pc 75794
sr 56
spc 75794
ssr 24
et 5
ed 131072
kep 0
ksp 0
epc 86444
I'll send an email off to XMOS too and see if I can get the early code and try that.

Thanks,
George

[bearcat]

While debugging at a breakpoint, in the dissassembly window you look for the blue arrow on the left to show what is the current instruction. That should be where the error is (as long as you are on the correct thread). It can be anywhere in the window.

If it is at the first instruction, that is an error. R9 is out of range as an L1 only has 64K memory and R9 is up at 128K. (That's my reading at least and I could be wrong, I am still learning myself). How R9 got that value would be the question of course.