Migrating from XHRA to XU208

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
jmag99
Member++
Posts: 27
Joined: Tue Jul 20, 2010 9:45 pm

Re: Migrating from XHRA to XU208

Postby jmag99 » Thu Mar 08, 2018 2:01 pm

There are instructions in the first post for how to create the bin. You will need a way to hold the xmos in reset while you program as well.
DHembree
Active Member
Posts: 53
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Thu Mar 08, 2018 4:13 pm

I'm pretty sure that only applies if you are programming via a JTAG header of some sort. My hardware does not have this, so I need to put the firmware into the QSPI device externally (it's mounted on an S08-DIP carrier) then install the memory into the system. I need to know if there is a .bin (or other) file that I can burn to the memory in this way.

Dan
jmag99
Member++
Posts: 27
Joined: Tue Jul 20, 2010 9:45 pm

Postby jmag99 » Thu Mar 08, 2018 4:50 pm

Yes, it's the same bin file you can create from the instructions in the first post.
User avatar
mon2
XCore Legend
Posts: 1063
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Mar 09, 2018 2:33 pm

I am perhaps old school but the approach I would take is to compile and build up the firmware to perform your task -> confirm this IP is working on the XMOS platform -> flash to your flash memory device. Then use xflash to read out the entire contents of the flash memory to a file. Then take this file and use any external programmer to insert into a blank device -> test again on the original XMOS platform -> if it works then only apply this physical flash memory onto your custom widget. There is a lot going on in these steps (including DFU details) and one small error will turn into a life sucking ordeal. We know that we have killed days on small "oops". Do not forget to ENABLE the QSPI bit as the XCORE-200 devices demand this on the original reference kits from XMOS. Likewise, do the same for your custom product. This is selected in the boot mode straps.
DHembree
Active Member
Posts: 53
Joined: Fri Apr 15, 2016 6:46 pm

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

Mon 2, Thanks again for your helpful input. I other things to sort out before I get to what you posted.

Today's question: in the original XHRA hardware there is a GPIO pin dedicated to MCLK_SEL, as well as a few unused GPIO pins. I have need of all of these, but cannot find a reference to them in any of them within the migration project. Can someone lead me to them, or explain how I can implement them?

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

Postby mon2 » Mon Mar 19, 2018 8:59 pm

Hi. Will try to review in detail later on but believe the routine of interest is

Code: Select all

     /* Configure Clocking/CODEC/DAC/ADC for SampleFreq/MClk */
     AudioHwConfig(curFreq, mClk, c_config, dsdMode, curSamRes_DAC, curSamRes_ADC);


This function is called when the audio core starts or changes sample rate. It should configure the external audio hardware to run at the specified sample rate given the supplied master clock frequency.


Not exactly sure where this routine is for a closer inspection but the original XRHA IP tickled GPIO3 as you have noted for this mclk_sel.


Image

Personally would not suggest to remove the use of this port pin. Hoping you can work around this using small pieces of logic or similar to expand your port pins. See if you can track down where the above routine resides for an inspection of the operation. Guessing that somewhere deep in the routine, the GPIO_3 pin (equivalent to which PORT?) will be found.
DHembree
Active Member
Posts: 53
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Mon Mar 19, 2018 9:12 pm

Yes, that's exactly the function I am trying to write code in, and GPIO3 is what I need to drive. I don't know where to look for configuration of, or reference to GPIO pins (X0Dxx) in the source files for the migration app. It seems I had previously seen some sort of 'map' somewhere in one of the perspectives, but I don't see it now. I figured Analyze, but it's not there.

There are also four additional GPIO pins in the original XHRA design. I am hoping to be able to access them as well.

I'm sure this is a walk in the park for some of you guys. Not me.

Dan
DHembree
Active Member
Posts: 53
Joined: Fri Apr 15, 2016 6:46 pm

Postby DHembree » Mon Mar 19, 2018 9:15 pm

I should note, my use of GPIO3 is identical to that of the original.
User avatar
mon2
XCore Legend
Posts: 1063
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Mar 19, 2018 9:22 pm

Found this so far from gpio_defines.h @ sw_usb_audio\app_usb_aud_xk_u8_2c\src\extensions (there are other copies of this header file from the same download). However, believe this is the bad boy you need to fix up.

Curious, how many ports do you really need? Are they output only? input only? GPIO? Perhaps there is a better way to support your needs and leave this area alone.

Code: Select all

/* General output port bit definitions (port 32A) */
#define P_GPIO_SS_EN_CTRL       0x001    /* SPI Slave Select Enable. 0 - SPI SS Enabled, 1 - SPI SS Disabled. */
#define P_GPIO_MCLK_SEL         0x002    /* MCLK frequency select. 0 - 22.5792MHz, 1 - 24.576MHz. */
#define P_GPIO_5VA_EN           0x004    /* Enable 5v power for DAC/ADC */
#define P_GPIO_LEDB             0x008
#define P_GPIO_LEDA             0x010
#define P_GPIO_USB_SEL1         0x020
#define P_GPIO_USB_SEL2         0x040
#define P_GPIP_CPR_RST_N        0x080    /* Apple CoProcessor Reset */
#define P_GPIO_ACC_DET_EN       0x100
#define P_GPIO_AUD_MUTE         0x200
#define P_GPIO_VBUS_OUT_EN      0x400
#define P_GPIO_RST_DAC          (1<<28)
#define P_GPIO_RST_ADC          (1<<29)
#define P_GPIO_DSD_EN           (1<<30)


#define P_GPI_DEVDET_SHIFT      0x0
#define P_GPI_DEVDET_MASK       (1<<P_GPI_DEVDET_SHIFT)
#define P_GPI_BUTA_SHIFT        0x01
#define P_GPI_BUTA_MASK         (1<<P_GPI_BUTA_SHIFT)
#define P_GPI_BUTB_SHIFT        0x02
#define P_GPI_BUTB_MASK         (1<<P_GPI_BUTB_SHIFT)
#define P_GPI_SW1_SHIFT         0x03
#define P_GPI_SW1_MASK          (1<<P_GPI_SW1_SHIFT)
User avatar
mon2
XCore Legend
Posts: 1063
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Mar 19, 2018 9:31 pm

Found it, blame it on Ross Owen :)

The way to hunt down this stuff like a dog is to look for a keyword and keep searching for it using Windows filemanager os similar tool - for example, searched for MCLK which led to other keywords, etc.

With a bit weight of 0x04 = GPIO_3 = P32A_CLK_SEL .

For the sake of sanity, best to leave the XMOS code as-is else you will have to continue to make the same changes (if any) anytime the firmware is updated in the future.

Code: Select all

/**
 * @file        port32A.h
 * @brief       Port 32A bit defines for L1 USB Audio board
 * @author      Ross Owen, XMOS Semiconductor
 */

#ifndef _PORT32A_OUT_
#define _PORT32A_OUT_

/* Bit defs */
#define P32A_USB_RST       0x01           /* ULPI rst line */
#define P32A_COD_RST       0x02           /* Codec rst line */
#define P32A_CLK_SEL       0x04           /* MClk Select line */
#define P32A_LED_A         0x08           /* LED A */
#define P32A_LED_B         0x10           /* LED B */

#endif

Who is online

Users browsing this forum: No registered users and 8 guests