Migrating from XHRA to XU208

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Re: Migrating from XHRA to XU208

Postby mon2 » Mon Mar 19, 2018 11:03 pm

This is making more sense now:

Code: Select all

    /* Put DAC in reset. All LEDs off */
    set_gpio((1<<P_GPO_DAC_RST_N), 0);


inside the XU208_XRHA folder parks the DAC and does the work. This means, you are free to use any available port pin as an OUTPUT to do the same. The GPIO0 & GPIO1 pins are to drive LEDs so really could be removed if not required.

this is from

Code: Select all

//:codec_init
void AudioHwInit(chanend ?c_codec)
{

    unsigned char data[1] = {0};

    i2c_master_init(i2c);

    /* Put DAC in reset. All LEDs off */
    set_gpio((1<<P_GPO_DAC_RST_N), 0);
DHembree
Experienced Member
Posts: 74
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Mon Mar 19, 2018 11:34 pm

My hardware previously worked perfectly with the XHRA-2HPA, though my design was a slight departure from the hardware reference design. The ref design used the SiLabs part for clock generation, while mine has two separate clock sources that MCLK_SEL selects. The XHRA data sheet refers to GPIO3 driving a similar select line. I believe this is where I got the idea.

Interestingly, I made a copy of the contents of audiohw.xc before I started modifying it's contents. There is no mention of:

/* Set master clock select appropriately */
if ((samFreq % 22050) == 0)
{
tmp &= ~P_GPIO_MCLK_SEL;
}


Very confused now.
DHembree
Experienced Member
Posts: 74
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Mon Mar 19, 2018 11:36 pm

I guess all I really need to know is - how can I modify the code or defines to make the source code play with my hardware nicely.
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Mar 20, 2018 2:09 am

Hi Dan. If the original XRHA processor worked in your custom board then so should the (properly) compiled XU208 replacement.

Have you tested this setup with the XU208 and compiled firmware? This is a long thread so not sure where you are on this testing.

If you do not have the Si5351A PLL then you could just comment out (do not recommend to delete the code from the source at this time) any call to use the Si5351A PLL. However, the original XHRA processor would be expecting the PLL and then time out so in theory, you should not have to remove the original PLL code.

Kind of feel your pain as your XHRA original PCB is probably lacking the XSYS connector so you must be injecting code using the processor in RESET and then asserting the code into the QSPI flash device? So this is very much trial and error to you nail it?

Start with the basics:

1) your flash device in QSPI mode with the bit enabled? This is important.
2) initially, code up a small routine to blink a LED using GPIO_0 and see if your XU208 processor continues to work with this blinky code - if not, something else is wrong. Very important to get the simple code working before moving forward with the rather complex audio IP.

What are the details of your external fixed clocks? What is the clock value when MCLK_SEL (datasheet label) = 0 ? What is the clock value when MCLK_SEL (datasheet label) = 1 ?

Again my usual disclaimer, not an audio person but have spent some time with the XRHA PCB to study its working. The folder for your interest should be the one from the first post in this thread. The audiohw.xc from the first post is the one of interest to modify for your project.

Other questions, with the XU208 installed + compiled firmware, does your custom PCB appear in Device Manager as the proper USB function?

Going to catch up on last night's Homeland episode and then will check back on your feedback a bit later...
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Mar 20, 2018 2:43 am

Dan, on your custom hardware, which port pin is controlling your DAC reset? Are you using GPIO3 or a different port pin?
DHembree
Experienced Member
Posts: 74
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Tue Mar 20, 2018 3:43 am

I painstakingly hacked a JTAG header on my existing hardware, so I can communicate with the board through my XTAG interface. Should have been a surgeon.

I should be clear that as of earlier today I have working hardware - correctly enumerates in Windows, and even plays audio. The initialization (AudioHwInit) section of my audiohw.xc works as expected and configures the DAC correctly for basic functionality (24 bit 48K PCM) What I am in the process of doing now is writing the hardware config section (AudioHwConfig) that handles changes in sample rates and PCM/DSD format changes. All of this code is based on what I had previously written for the XHRA using it's config utility.

My mclk source is comprised of two precision fixed clock oscillators (22.579MHz and 24.576MHz), each with an enable input. MCLK_SEL is supposed to drive the enable inputs (one is driven through an logic inverter) and the AudioHwConfig drives that based on the incoming sample rate. I have a switch statement monitoring samFreq and writing MCLK_SEL accordingly. If I can figure out how to use/alter the available GPIO, as it did with the XHRA, to do this I'm just about done. I just don't know how or where to configure GPIO. I don't understand how to access code in another app (gpio_access.h etc...)

Hope this makes sense. Hope you enjoyed your show!

Dan
User avatar
mon2
XCore Legend
Posts: 1254
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Mar 20, 2018 12:12 pm

Hi Dan. Please test the attached file but first rename back to audiohw.xc and then replace the original.

Added a #define HAVE_EXTERNAL_PLL that is commented out. Leave this as a comment to remove the PLL access and use your external fixed clocks.

Hope you enjoyed your show!


Postponed to tonight. Far too often I pass out and miss the good stuff so better to watch when less tired. Rumor has it that Brody will make a come back (from the "dead") this season so it should be interesting. Never believed he really was dead but the internet chatter is reporting that the writers were flooded with complaints and requests to bring him back. So they will. Perhaps Carrie will have hallucinations about him being alive from her strong medications or something. Either way, he is an amazing and talented actor. This show and Breaking Bad have to be at the top of my list of must see TV.

Please post your results.
Attachments
audiohw_revised.xc
(9.18 KiB) Downloaded 106 times
audiohw_revised.xc
(9.18 KiB) Downloaded 106 times
DHembree
Experienced Member
Posts: 74
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Wed Mar 21, 2018 5:10 am

Mon2,
Simply adding the line:

set_gpio((1<<P_GPO_DAC_RST_N), 0);

where appropriate in my existing audiohw.xc did the trick. I'm not sure where the interchange between reset and mclk sel occurred, but at this point I don't care. It's working!

Thanks a million!
Ivo71
New User
Posts: 2
Joined: Tue May 22, 2018 6:04 pm

Postby Ivo71 » Tue May 22, 2018 6:55 pm

Hi,
My XU208 custom hardware covered the XHRA-2HPA reference board without DAC.
Use xhra2xu208_1v0 software over sw_usb_audio-[sw]_6.15.2rc1, but I observe the following strange behavior. It works only in default sample rate 48kHz but start with few seconds delay. If try to change to other sample rate the device stuck in, the player also stuck and both LEDs are on. Does anyone have the same problem or idea hot to resolve this ?
User avatar
infiniteimprobability
XCore Legend
Posts: 1113
Joined: Thu May 27, 2010 10:08 am
Contact:

Postby infiniteimprobability » Wed May 23, 2018 1:43 pm

Does anyone have the same problem or idea hot to resolve this ?


Did you customise the 4 files mentioned in the first post of this thread for your hardware? If the firmware is trying to do I2C transactions with no physical slave present, it would behave similarly to what you have described.

Who is online

Users browsing this forum: No registered users and 12 guests