Migrating from XHRA to XU208

Discussions about USB Audio on XMOS devices
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Ok. Consider to use the revised I2C pin mappings to now ping your external I2C device. Most I2C devices have some read only component ID that can be read back by the I2C master.

Insert some debug code (printf or copy the read contents to some local variable) and then place code breaks to inspect the read values. Use this approach to read out a known good ID from the I2C device(s) to confirm the routines are operational up to this point of the code run.

An I2C bus analyzer (Total Phase or similar) would be helpful here as well but not absolutely necessary...yet. If necessary, you can also consider to really slow down the I2C bus speed, at least till this test is known to be working properly. Curious on your results.


shaw
Active Member
Posts: 43
Joined: Fri Mar 25, 2011 12:36 am

Post by shaw »

We don't have a DAC directly connected to XMOS processor. The I2S bus is passed on to downstream CPLD and DSP. So only device on XMOS processor I2C bus is the Si5351(not DAC). I will look if I can read an ID from that, but I haven't found correct register yet.
Tomorrow, I will verify that SI clock generator does generate expected clean clocks. I will check when switching between 44.1K and 48K sampling rate files, that XMOS_MCLK_SEL goes to correct state and proper clock is input at XMOS_MCLK.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Read out register 183 and confirm that bits 7,6 = "11" as these are power on / reset defaults for the cap load capacitance - see AN619 by Silabs:

Code: Select all

Reset value = 11xx xxxx
then read register 177 or some other that is all 0 as a power on default. Loop between the 2 register reads - are the read results consistent and without mismatches?
Attachments
silabs_si5351_default.png
(47.46 KiB) Not downloaded yet
silabs_si5351_default.png
(47.46 KiB) Not downloaded yet
shaw
Active Member
Posts: 43
Joined: Fri Mar 25, 2011 12:36 am

Post by shaw »

It now works. The problem was in the I2C function. I hadn't fully removed the Sabre dac communication that was in the base code, given we don't have a dac connected to I2C/I2S. So it was getting hung waiting for response from DAC.

infiniteimprobability and mon2, thank-you very much for the help.
MDuprau
Junior Member
Posts: 6
Joined: Wed Sep 26, 2018 11:27 pm

Post by MDuprau »

Hello,

i have the same problem like other members here, i must replace the XHRA with the XU208 on a custom board with a shema thats near 100% on XHRA reference, except two SN74CB3Q3245 there will switch the QSPI bus from XMOS to ATXMEGA if the XMOS is offline (no USB connected).
I read this thread more than ones, check all the hints, read docs, but it will not work.

Here is a checklist i have done (X], answer [A] or there are open questions [?], atm. i stuck i hope someone here have an idea whats wrong :
[X] use XU208-128-TQ64-C10 as XHRA-2HPA-TQ64-C replacement
[X] download USB Audio 2.0 Device Software - source code 6.15.2rc1
[X] Download xhra2xu208_1v0.zip
[X] Download and unzip this source package
[X] Copy over the top of a fresh 6.15.1rc2 (latest released version) reference design download. Note you will need to copy into the root of the reference design project so that the sw_usb_audio and sc_usb_audio subdirectories are correctly overlaid. Download from here https://www.xmos.com/support/software/uac2
[X] Make sure you have a copy of the XMOS tools. We used 14.3.2 (14.3.3 here) to test this. Download from here https://www.xmos.com/support/tools where you can also find links to user guides and programming docs
[X] Build the "app_usb_aud_xu208_xhra" project. Please see usual documentation for doing this: https://www.xmos.com/download/private/s ... ha1%29.pdf
[X] Download to your XU208 or program the flash. To make a raw binary file suitable for programming a SPI FLASH, you can use xflash -o app_usb_aud_xu208.bin --noinq --boot-partition-size 2097152 bin/app_usb_aud_xu208_xhra.xe. Note that the boot partition size has been set to the whole flash device, in this case, a 16Mb IS25LQ016B. The boot partition has the bootloader, factory image and upgrade image in it. Please consult the tools documentation for more info on this.
[X] H Schematics Design Check List
--[X] This section is a checklist for use by schematics designers using the XU208-128-TQ64. Each of the following sections contains items to check for each design.
--[X] H.1 Power supplies
----[X] The VDD (core) supply ramps monotonically (rises constantly) from 0V to its final value (0.95V - 1.05V) within 10ms (Section 12).
----[X] The VDD (core) supply is capable of supplying 375mA (Section 12 and Figure 24).
----[X] PLL_AVDD is filtered with a low pass filter, for example an RC filter, see Section 12.
--[X] H.2 Power supply decoupling
----[X] The design has multiple decoupling capacitors per supply, for example at least four0402 or 0603 size surface mount capacitors of 100nF in value, per supply (Section 12).
----[X] A bulk decoupling capacitor of at least 10uF is placed on each supply (Section 12).
--[X] H.3 Power on reset
----[X] The RST_N pins are asserted (low) until all supplies are good. There is enough time between VDDIO power good and RST_N to allow any boot flash to settle. RST_N is fast enough to meet USB timings.
--[X] H.4 Clock
----[X] The CLK input pin is supplied with a clock with monotonic rising edges and low jitter.
----[X] You have chosen anYou have chosen an input clock frequency that is supported by the device (Section 7)
[X] Power is OK and sequenced (3v3 first)
[X] Reset properly deasserted
[X] Clock present and correct (this project is expecting 24M on CLK)
[X] Boot mode set correctly. Leaving the QSPI data lines with no pull-ups (which means internal pull downs will win) sets the chip to boot from QSPI master
[X] I would reccomend double checking the value on the QSPI data pins when the chip is in reset to ensure that they are all low (boot from QSPI master). The device applies a weak (30kish) pull down on these pins in reset.
[X] USB Vbus has the recommended filter to limit the inrush current? **very important** else you will face field failures. for our USB designs, we use the Diodes Inc. USB load switch which has a number of nice features including soft-start, etc. in a single device.
[X] SS (slave select) is pin X0D01 if using boot from QSPI master
[A] anything else camped (other loads?) onto X0D01 pin? (NO here)
[A] the boot flash is enabled with the QSPI bit = 1 for QSPI mode? (yes here)
[A] Although the XMOS processor needs to access the flash using X0D01 pin being high. (1K0 here)
[A] Please confirm that you had a strong pull-up (1k was used by the XMOS XHRA ref design) on the CS of the flash device. (1K0 here)
[A] Confirm again that the power rails are stable. Perhaps the XU208 consumes more current than the original XHRA processor? (LM3674MF-ADJ, 600mA here)
[A] Silabs clock generator (PLL) is ok for at least the required 24M line? (https://www.digikey.de/products/de?keyw ... -1252-1-ND here)
[A] The ADUM1085 is an open-drain reset supervisor. Does the output of this supervisor go high ok? Would not hurt to apply an external pull-up if you do not have in for this circuit. Believe that the XMOS device has an internal pull-up for the RST_N pin but again, will not hurt to apply one to be sure the CPU is released from reset. (No Pullup, 2V5 here)
[A] The XU208 features a metal belly pad which could be fun to solder. Confident that this required metal belly is soldered? This is a ground pin to the device. This missing pad could be a root cause of the non-working boards. (Reflow here)
[?] gpio_defines.h @ sw_usb_audio\app_usb_aud_xu208_xhra\src\extensions is right ?
#define P_GPO_LED_A 0
#define P_GPO_LED_B 1
#define P_GPO_MCLK_SEL 3
[?] reason why "set_gpio((1<<P_GPO_DAC_RST_N), 1);" can/must replace "set_gpio(1<<P_GPO_MCLK_SEL, 1);" ?
[A] Other questions, with the XU208 installed + compiled firmware, does your custom PCB appear in Device Manager as the proper USB function? (NO here)
[?] compile project "app_usb_aud_xu208_xhra" with "Makefile" -> Target "xhra_xcore" (default) for the "XU208-128-TQ64-C10" ?
[?] HEX-Dump from "app_usb_aud_xu208.bin" : "7d 30 00 00 f3 37 00 09 00 b5 00 00 00 00 02 00" it looks differently from other BIN-files i have seen here, is that the right start sequence ?
[X] program "IS25LQ016B-JNLE" with data from "app_usb_aud_xu208.bin" in MSB / LSB, both dint work
[X] i see communication (scope) on the QSPI bus from "XU208-128-TQ64-C10" to "IS25LQ016B-JNLE"
[?] initialisation/update for the XMOS flash "IS25LQ016B-JNLE" goes over a ATXMEGA (XU208-128-TQ64-C10 is offline in this case), is there a need to change the data from "app_usb_aud_xu208.bin" or can it program one by one ?

Best regards Mark Duprau (Forge Audio)
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi Mark. The cpu is strapped to boot from a QSPI flash. Respectively, the QSPI bit inside the flash must be enabled. Please confirm this important detail.

Does your custom pcb offer a xtag interface? If yes, you could use a small piece of code to throw the standard SPI commands to configure the QSPI bit. Also believe xflash can do this for you but you must treat the flash as QSPI capable by passing the proper parameters. Personally have not used this xflash method.

Please post your results.
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

The first page of this thread refers to 6.15.1rc2. The link seems to point to 6.15.1rc1 only.
MDuprau
Junior Member
Posts: 6
Joined: Wed Sep 26, 2018 11:27 pm

Post by MDuprau »

mon2 wrote:Hi Mark. The cpu is strapped to boot from a QSPI flash. Respectively, the QSPI bit inside the flash must be enabled. Please confirm this important detail.

Does your custom pcb offer a xtag interface? If yes, you could use a small piece of code to throw the standard SPI commands to configure the QSPI bit. Also believe xflash can do this for you but you must treat the flash as QSPI capable by passing the proper parameters. Personally have not used this xflash method.

Please post your results.
Snip from debug log :
* extender.usb.audio
- SPI open
- flash.id: 149D
- set state.qe=0
- state: 00000000
- data.chksum: 3719
- flash.chksum: 8B79
- flash erase
- flash.data=base.addr[00000000] size: 5B00
- set state.qe=1
- soft.reset

Yes, QSPI bit is set
No, for the XTAG interface
On the [?) in the list i am not sure, have anyone here answers ?
I use "6.15.2rc1" is there a newer one ?

Best Regards Mark Duprau
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Mark,

1) try to boot a simple led blinky code on your custom pcb. Does that boot from your flash and work?

2) if yes, try different usb cables that are fully loaded (4 wires) and your usb audio ip. Work? No, then apply xmos usb ip like usb cdc, usb hid to validate if any usb ip works on your pcb.

3) if still failing, post relevant parts of your schematic in pdf format for a review.
DHembree
Experienced Member
Posts: 75
Joined: Fri Apr 15, 2016 6:46 pm

Post by DHembree »

Does anybody have 6.15.2rc2?

It's mentioned a few place on this thread, but the link on the first page is -rc1

Thanks,
Dan
Post Reply