Page 13 of 19

Re: Migrating from XHRA to XU208

Posted: Mon Sep 17, 2018 11:53 am
by shaw
Hmm sounds like the problem is on sample rate change. Could be AudioHwConfig is getting stuck. (where does the debugger say the audio thread is?)
The audio task is running on tile[0] core[0].

Try commenting out suspect bits if that function - could be I2C config issue?
I am running in master mode so Xmos generates clocks. I am monitoring I2S directly, so dac Not in the picture just yet. Am i missing the intent of debugging possible I2C config issue?

Since our new board is identical to the XK-USB-AUDIO-HPA evaluation board, but with the obsolete HXRA device replaced with an XU208 device. A good first step might be to try "someones" working app_usb_aud_xu208_xhra.xe file. If that makes sense, could someone attach the standard migrated .xe file, It looks like it is smaller than a 1MB. I can then assess if I made a software migration mistake or if the problem is in our hardware somewhere.

Thanks,

Re: Migrating from XHRA to XU208

Posted: Mon Sep 17, 2018 1:35 pm
by akp
I think "where does the debugger say the audio thread is?" may mean, when you run under the debugger, what part of the code is the audio thread stopped on?

Re: Migrating from XHRA to XU208

Posted: Mon Sep 17, 2018 3:02 pm
by shaw
when I stop the debugger, it always stops on an instruction in the Deliver() main while loop. It stops on different instructions and I'm able to single step to next instruction, so it doesn't seem hung up waiting for something. I can set breakpoints in this main loop at various instructions and it hits the breakpoints.

Re: Migrating from XHRA to XU208

Posted: Tue Sep 18, 2018 8:34 pm
by shaw
Would it be possible for someone to supply the working app_usb_aud_xu208_xhra.xe file for the standard XK-USB-AUDIO-HPA evaluation board? Our board is identical and I think it would help us isolate if this is a software migration issue or a hardware issue. Would be much appreciated.

Re: Migrating from XHRA to XU208

Posted: Thu Sep 20, 2018 9:43 pm
by shaw
I'm still not having much luck resolving this migration. The two issues are:
1: No I2S data out. (monitored with logic analyzer)
2: I2S Sampling rate doesn't change when a new audio file with new sampling rate is played. (monitored with logic analyzer)

Here are some notes:

DATA OUT:
I play a wav file . I insert a breakpoint in the audio.xc file at lines 766, in the middle of play. I look at samplesOut array[] when is breaks. Data is always zero'ed.

SAMPLING RATE:
1: Start debugger running code, I2S LR clock goes to default 48Khz rate.
2: I play a 96Khz wav file on Jriver, It plays as far as Jriver is concerned. But the I2S LR clock stays at 48Khz on logic analyzer.
I set a breakpoint at line 365 in audiorequest.xc / AudioClassRequest(). I then play a 96Khz wav file. The breakpoint is hit. The variable g_curSamFreq has a value of 96K, as expected. I reset everything and move the breakpoint to line 370 and repeat steps 1 and 2. This breakpoint is never hit.

Thanks for any assistance with interpreting what is going on.

Re: Migrating from XHRA to XU208

Posted: Fri Sep 21, 2018 1:32 am
by mon2
Hi @shaw.

1) Have you posted a schematic of the vitals of your design in this thread? If not, please consider to do so as they are far too many variables. Hardware and software that can impact any such design.

2) What is the clock source for your audio widget? Is it the Si5351A PLL that was defined by XMOS?

It is your custom PCB that is able to enumerate as a USB device? If yes, that is a very good start for sure which implies you must be feeding in a 24 Mhz clock for the USB framing.

Not an audio developer but let us start with the schematic to be sure that is on track - ok that was an audio related pun :)

Re: Migrating from XHRA to XU208

Posted: Fri Sep 21, 2018 3:00 pm
by shaw
Hi mon2

1) Have you posted a schematic of the vitals of your design in this thread? If not, please consider to do so as they are far too many variables. Hardware and software that can impact any such design.
Not yet. I will post once I get okay to do so.

2) What is the clock source for your audio widget? Is it the Si5351A PLL that was defined by XMOS? Yes

It is your custom PCB that is able to enumerate as a USB device? Yes

If yes, that is a very good start for sure which implies you must be feeding in a 24 Mhz clock for the USB framing? Yes

Not an audio developer but let us start with the schematic to be sure that is on track - ok that was an audio related pun :) (background rimshot)

Re: Migrating from XHRA to XU208

Posted: Sat Sep 22, 2018 12:07 am
by shaw
I have attached the relevant part of the schematic.

Re: Migrating from XHRA to XU208

Posted: Sat Sep 22, 2018 6:33 pm
by mon2
Hi @shaw. Believe that inifiniteimprobability's hint may be spot on and from a quick review of your partial schematic...

you may have reversed the hardware mappings for the I2C lines (SCL & SDA).

See the the thread here:

http://www.xcore.com/viewtopic.php?f=26 ... tea#p33957

Code: Select all

http://www.xcore.com/viewtopic.php?f=26&t=6852&p=33957&hilit=strong+tea#p33957
That is, the XMOS I2C library is expecting, by default, for the lower bit weight pin to be I2C_SCL pin and respectively, higher bit weight to be I2C_SDA.

Your current posted schematic shows:

I2C_SCL @ X0D15
I2C_SDA @ X0D14

which is reversed

and really should have been:

I2C_SCL @ X0D14
I2C_SDA @ X0D15

to use the XMOS I2C library as-is. However, the simple fix is to just search for all such I2C lib calls inside your source code and reverse the bit weights to match your true hardware mapping. No rework of the hardware should be necessary for this bug fix.

This is the beauty of XMOS IP being all in software :)

The above thread references the same issue and work around.

Please review and post your results. Hope to *hear* some good news :) (Yes, another audio pun :)

Re: Migrating from XHRA to XU208

Posted: Sun Sep 23, 2018 9:50 pm
by shaw
mon2, thank-you for taking the time to look at this. Good find. Here is what I've done so far.
I made the change below on the definition of a I2C clock data high, trying to switch respective port placement. It didn't have the effect I expected, so I will look more closely when I am back in the office on Tuesday . I will try a few more things here, before then. I will report back on findings.

/** This constant defines the bit value of a high data bit on the I2C port. The default value is 1, meaning that this is on bit 0 of the port. Set to 2, 4, 8, ... for other bits of the port. */
#define SDA_HIGH 2 // previously 1
/** This constant defines the bit value of a high clock on the I2C port. The default value is 2, meaning that this is on bit 1 of the port. Set to 1, 4, 8, ... for other bits of the port. */
#define SCL_HIGH 1 // previously 2