Migrating from XHRA to XU208

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Re: Migrating from XHRA to XU208

Postby shaw » Mon Sep 17, 2018 11:53 am

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,
User avatar
akp
XCore Addict
Posts: 209
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Mon Sep 17, 2018 1:35 pm

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?
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Mon Sep 17, 2018 3:02 pm

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.
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Tue Sep 18, 2018 8:34 pm

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.
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Thu Sep 20, 2018 9:43 pm

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.
User avatar
mon2
XCore Legend
Posts: 1298
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Sep 21, 2018 1:32 am

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 :)
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Fri Sep 21, 2018 3:00 pm

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)
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Sat Sep 22, 2018 12:07 am

I have attached the relevant part of the schematic.
Attachments
schematic2.png
(302.86 KiB) Not downloaded yet
schematic2.png
(302.86 KiB) Not downloaded yet
User avatar
mon2
XCore Legend
Posts: 1298
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Sat Sep 22, 2018 6:33 pm

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:

viewtopic.php?f=26&t=6852&p=33957&hilit=strong+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 :)
shaw
Member++
Posts: 25
Joined: Fri Mar 25, 2011 12:36 am

Postby shaw » Sun Sep 23, 2018 9:50 pm

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

Who is online

Users browsing this forum: No registered users and 35 guests