XHRA-2HPA USB Audio, JTAG and QSPI FLASH Usage/Programming

[lchenier]

Hi!

We have received our board which uses a XHRA-2HPA processor and currently debugging it. I’ve started using xTimeComposer (14.1.2) and have a few questions:

1) xCORE-AUDIO Hi-Res 2 Firmware Image [sw] available on your web site (https://www.xmos.com/support/boards?product=18340) seems to be at version 1.1.0rc1 but it looks like the latest and greatest version is 6.12.6 according to the changelog file – correct? Do you have a binary with the latest and greatest? Or do I need to build it?

2) According to AN00103 (1.0.2) it looks like we should be using app_usb_aud_xk_u8_2c with 2xoxxd configuration (we want I2S/DSD out only (no SPDIF or MIDI) with DoP enabled, up to DSD256 would be nice). Where do I select the processor type (XHRA-2HPA)? In the xk_usb_audio_u8_2c.xn configuration? If so, what should be the Package ID and Type?

3) The XHRA-2HPA-TQ64-C does not have any JTAG port (unless some of the N/C pins are actually the JTAG…). What is the best way to debug it? Should I be using the XU208-256-TQ64 instead?

4) We are using our local micro to program the QSPI chip attached to the XHRA-2PHA. Version version 1.1.0rc1 shows the following data:

D3 70 00 00 53 37 00 09 00 0A 00 00 ...

Is this means that the QSPI flash should be programmed with 0xD3 at location 0 and 0x70 a location 1? Or should the nibble be reversed (i.e. 0x3D and 0x07) like have seen in an app note for another XMOS processor?

Thanks in advance for your help!

Louis

[Ross]

Please can you update the topic to something useful, we aim to provide a useful and reusable resource for everyone.

[henk]

3) The XHRA-2HPA-TQ64-C does not have any JTAG port (unless some of the N/C pins are actually the JTAG…). What is the best way to debug it? Should I be using the XU208-256-TQ64 instead?

The XHRA-2HPA-TQ64-C is not a programmable device - it is a fixed function device that can only perform the functions described in the XHRA-2HPA-TQ64-C data sheet. Hence, there is no need to debug and no method to debug it. Also, it can not execute the USB audio stack.

This also answers questions 1 and 2 - the XHRA chips are just fixed function chips that are unrelated to the USB audio stack.

For executing USB audio, you need a programmable device, such as the XUF208.

4) We are using our local micro to program the QSPI chip attached to the XHRA-2PHA. Version version 1.1.0rc1 shows the following data:

D3 70 00 00 53 37 00 09 00 0A 00 00 ...

Is this means that the QSPI flash should be programmed with 0xD3 at location 0 and 0x70 a location 1? Or should the nibble be reversed (i.e. 0x3D and 0x07) like have seen in an app note for another XMOS processor?

It is very likely that nibbles should be reversed if you use another Micro. Don't forget the bit to state that the chip is in QUAD mode, otherwise it won't be able to read it.

Hope this helps,
Henk

[lchenier]

The XHRA-2HPA-TQ64-C is not a programmable device - it is a fixed function device that can only perform the functions described in the XHRA-2HPA-TQ64-C data sheet. Hence, there is no need to debug and no method to debug it.

This means that the code is pre-loaded in the chip? External QSPI chip is ONLY used for configuration? If that's the case, why is there a bin file shown under https://www.xmos.com/support/boards?product=18340. The latest datasheet does not show a QSPI attached to the chip in the "typical" application diagram, but a previous version (2015/07/09) does.

The XK-USB-AUDIO-HPA eval kit seems to be loading code from the external QSPI FLASH. There's activity on the SPI bus for about 55 ms after reset - a lot more than just a few configuration bytes..

Also, it can not execute the USB audio stack.

https://www.xmos.com/download/private/x ... 1.3%29.pdf clearly states that the chip is USB Audio Class 2.0 compliant.

Don't forget the bit to state that the chip is in QUAD mode, otherwise it won't be able to read it.

Setting the bit in the SPI memory to go in QUAD mode was the trick - thanks!

Thanks in advance for additional feedback.

Louis

[henk]

Hi Louis,

Glad you got it to work!

Apologies for putting you on the wrong leg about USB Audio compliance.

The XHRA-2HPA chip is a USB Audio-2 compliant end point, that has a limited configuration option. When I wrote that it couldn't run the USB Audio Stack, I meant, that you cannot compile the USB audio stack with a set of options of your choosing and run it on it. The XHRA-2HPA chip implements one specific version of USB Audio-2.

Re the external flash - it does need an external flash to contain the code, but you cannot change the code in it.

With XMOS kit there are two ways that you can make a USB-Audio endpoint. You can either buy

1) an XHRA-2HPA chip, stick a flash next to it, load the image onto flash, and Bob is your uncle; or buy
2) an XUF208 chip, download the USB Audio code project, compile it, and flash it onto the XUF208 using an XTAG3

Both are USB-Audio compliant. You can configure and reprogram (2) to implement no end of funky features that you come up with, but you can only change (1) within the boundaries of what the pre-compiled binary allows you to. In other words option (1) is something that just works; you don't need to worry about tool-chains, JTAG, etc. However, if you are fine with these, then choosing option (2) gets you the swiss-army knife of USB Audio products.

Hope that clarifies things,
Henk

[lchenier]

Hi Henk,

Thanks for the clarification.

Actually not quite there yet :-(

Data seems to be retrieved from the QSPI (there's activity for about 50 ms) and eventually CS goes back high (after another 50 ms or so) but when plugging a USB cable to the device, no attach event is seen (i.e. D+ or D- are NOT going high). None of the status lines (e.g. USB_HOST) are changing (all low). PC obviously does not report that a new USB device is attached.

- Voltages (i/o and core) are OK.
- Clocks (24MHz and audio mclk) are applied, reset stays de-asserted and I've checked continuity from the USB cable pins up to the chip pins.
- Chip seems to be soldered properly.
- Also tried adding configuration bytes at address 0x80000 (same example as shown in annex A2.5 of the user's manual except the I2C write to the DAC and adjusting lenght). I am NOT seeing the \CS asserted at the end of the boot sequence - shouldn't it be as it is accessing a completely different address?
- USB cable works with another device.
- I've tried another board too, just in case, but no success.

Any suggestions?

Louis

[henk]

Is it worth trying with non-swapped nibbles; just in case your programmer swaps nibbles?

[lchenier]

Already tried - boot time becomes very short in this case (<10 ms) which is way too short when transferring 40K bytes with a clock @ 2.4 MHz.

Any other suggestions?

Louis

[henk]

Two questions.

Did you say it made a difference whether you programmed 0x80000 or not?
In that case, the chip boots fine, but does not like its setup sequence.

(the chip will first load and decode the boot image, then start that, and then load configuration data in a second stage).

How is the PCB laid out - in particular, how are you programming the QSPI flash - is there a connector that gives access to the 6 QSPI wires?

[lchenier]

Did you say it made a difference whether you programmed 0x80000 or not?

No difference.

How is the PCB laid out - in particular, how are you programming the QSPI flash - is there a connector that gives access to the 6 QSPI wires?

The QSPI is programmed by our local host micro. We do an erase/write/read/verify to make sure the memory is programmed properly. We also have 22R resistors located close to the QSPI memory going to the host micro. Scoping the various signals looks like we have good levels/good margins.

Does any of your config try to access an external I2C device? It could be hung up trying to access a decoy on bad address or similar.

We've made sure there was no I2C access.

We've connected the XHRA-2HPA eval board QSPI memory (keeping the processor on the eval board in reset) to our board without any success either. We've also noticed that the content programmed in the eval board is NOT the same as xCORE-AUDIO Hi-Res 2 Firmware Image [sw] (version 1.1.0rc1). Is this normal?

Louis