XVF-3510 development and USB device

[Kevin Jordan]

I'm new to the XMOS chipset and the SDK. I bought the XMOS XVF3510 developer kit (XK-VF3510-L71-AVS). The device worked fine as a I2S device directly on the Raspberry Pi, but we are changing directions and would like to have the XVF3510 as a USB device instead.

Is there a guide to getting this XMOS chip/Devkit to work as a USB device? I plugged the USB part of the the DevKit into the Raspi, my windows computer, and a Mac, it did not show up as a sound card or mic input on any of these devices.



The USB lines are connected to the XVF3510, but I'm assuming I need to program the chip with the XTAG programmer to enable the USB functions. I have the XTAG programmer, but I'm not sure where to start with xTimeComposer.

I know the XVF-3500 chip can do this, as ReSpeaker and Acusis both show up as a sound card.

Is there a guide or example project to work with xTimeComposer to have the chip show up as a USB sound card? Has anyone else been able to have this chip come up as a USB device?

Thanks!
--Kevin

[mon2]

Hi Kevin. Welcome to the forum.

Yes, it is possible to reflash the XMOS CPU to make it behave as a USB device. The CPU is very flexible and capable of morphing into assorted shapes including an ultra fast GPIO bit banging device to support Gigabit Ethernet; Audio devices; USB functions, etc.

On this topic, the website and appnotes are a bit scattered so recommend that you use Google to find the juicy stuff.

The first suggestion is to consider the following Application Note to morph the CPU into a USB CDC device -> will create a serial port on your Windows / Linux box with ease for quick testing.

https://www.xmos.com/?s=AN00124

There are other similar application notes like USB Keyboard HID, etc. but the USB mouse application is a solid one to initiate your development.

If you do consider to spin your own XMOS widget, do seriously consider to post a partial schematic before shipping to a PCB shop for a quick review. The XMOS CPU does demand power up sequencing before releasing the #RESET line; power rails to be a certain current; recommend impedance controlled traces with ESD protection and EMI filters. Also do hunt down the USB VBUS advisory which can result in a voltage spike due to the mated USB cable length and this can kill the CPU!! There are some excellent USB load switches which can help here from Diodes Inc., etc. At the very minimum, review the datasheets which do mention this errata.

Hope this helps.

[Kevin Jordan]

ok, I downloaded the firmware and tried to download to the XTAG device but I'm getting errors from my PC and my Ubuntu box doesn't show up correctly.

Windows 10:

C:\XMOS\VocalFusion-XVF3510-binaries_v0.12.0>xflash --list-devices

Available XMOS Devices
----------------------

ID Name Adapter ID Devices
-- ---- ---------- -------
0 XMOS XTAG-3 2KbYj_za O[0]


C:\XMOS\VocalFusion-XVF3510-binaries_v0.12.0>xflash --id 0 "XM-013711-SM-G-XVF3510 I2S Firmware binary.xe"
xflash: Warning: F03148 --quad-spi-clock not given, using default 15.62MHz
Error: F03013 Failed to run : 00C9EC10.


----
XMOS support told me to contact Digikey. Is there a quick fix?

For Ubuntu:
I got to a point in the documentation where it says you have a custom patched " Linux FTDI Library Request "
-----
If your distribution does not support USBFS and does not have a /proc/bus/usb directory (this
is the case on newer kernels, from approximately 2.6.32 onwards), you may contact XMOS for
an unofficial patched version of the device library
-----


Is the library for Ubuntu posted?

I also tried with my Macbook pro on the newest OSX. It denied me opening the file at all.

[mon2]

Hi. Missed this post. Did you get issue this resolved?

XMOS support told me to contact Digikey. Is there a quick fix?

Digikey are good people but they will know how to fix this issue? Thinking not...

Which XMOS toolchain version did you use to compile this project?

Suggest to consider Windows for development and then test on other platforms to be sure you have the firmware working correctly.

[Kevin Jordan]

Thanks for your advice, mon2.

I now have a few proto boards printed and assembled. I got my Mac laptop to be able to flash the code to the dev board from the XMOS xTAG3, but when I connect to my new prototype boards I designed, I'm getting nothing in response when I list boards:

This is what I see when connected to my dev board:

Code: Select all

bash-3.2$ xflash --list-devices

Available XMOS Devices
----------------------

  ID	Name			Adapter ID	Devices
  --	----			----------	-------
  0 	XMOS XTAG-3         	2KbYj_za	O[0]

it works fine, but when I connect to my powered up proto board:

Code: Select all

bash-3.2$ xflash --list-devices

Available XMOS Devices
----------------------

  ID	Name			Adapter ID	Devices
  --	----			----------	-------
  0 	XMOS XTAG-3         	2KbYj_za	None

Is there some initial firmware I need to flash on the chip? If so, where would I get that firmware?

[mon2]

Hi. At this stage of testing, the results of the list command should match. That is, even a blank firmware CPU on your custom PCB should show the same output as the development board.

The xtag3 board (aka JTAG) is scanning the JTAG chain and reporting all found devices. At this time, the custom PCB is not returning the valid responses.

Suspecting that there is some hardware issue with the custom PCB.

Please post your schematic of the custom PCB for a review.

Double check your soldering of the custom PCB.

Voltages match the checklist in the CPU datasheet?

Voltage sequencing has been met as per the CPU datasheet?

[Kevin Jordan]

Attached is the schematic for the entire board. I don't have a XRAY but I do have a good macro lens. All connection points on the QFN look like good connections.

Voltages match the checklist in the CPU datasheet?

Yes, I have a good 1v, 3.3v and 5v.

Voltage sequencing has been met as per the CPU datasheet?

I'm going to check this now. Will update as soon as I check it.

[mon2]

Hi.

First thing to note is that the RESET supervisor is open drain. With your current setup, power up and check the voltage on #RESET of the CPU line / pin 1 of U12.

Then hard short pin 1 of U12 to GROUND and release after a few seconds. Try your XTAG3 scan again after this procedure.

Ok to bypass the BAT54A diode by shorting pins 1 & 3 of this dual diode array. The XTAG3 is also open-drain so the outputs can be shared. Correction: My bad - DO NOT do this. The XMOS kits feature yet another open drain buffer and THEN you can share the outputs. For now, use the idea of manually shorting the #RESET to ground to pulse the reset line. The proper design should have another open drain buffer from the XTAG3 tool as shown in the XMOS ref kits.

Test again to see if this changes the test results with your custom PCBA.

Other areas to review...

1) What is the measured voltage for your 1v0 rail? What are the exact stuffed values for R3 & R4 (Vfb resistors)? This buck regulator is marked as NRND.

2) As a general rule, the voltage sequencing is very important to prevent possible latch up of the CPU. The guidelines in the datasheet recommend:

a) monitor the +3v3 rail with a voltage supervisor -> once this threshold is met, use the PG signal from this 3v3 supervisor to enable the +1v0 rail.
b) monitor the +1v0 rail with a voltage supervisor -> once this threshold is met, use the PG signal from this +1v0 supervisor to release the #RESET of the CPU.

For the above reasons, suggest to rework the +3v3 voltage supervisor (U12) to enable the +1v0 buck regulator (not the #RESET signal).

Then add another +1v0 supervisor that can trigger @ 0.9v to release the #RESET signal.

You may have some luck as-is with the design but the above is highly recommended. In the mean time, do check if the #RESET line is truly HIGH after a power up or is it still LOW which would then halt any activity of the XTAG3 (JTAG) traffic.

c) Pin 61 (CPU middle paddle connection) must be mated with GROUND. Often, this is a root cause of such issues as observed from a long list of OEM design reviews. Would not hurt to throw some hot air onto the CPU to guarantee the middle belly pad is truly grounded.

d) Remove R46 as it is not required, R41 serves this PU purpose for #CS of the QSPI flash device.

e) not related but preaching hat is on - there MUST be some form of ESD protection on the USB lines else you will face returns due to Stephen King storyline events that will damage your widget. From memory, we found that the TI ESDS312 is the best in the marketplace as of this writing. If cost is really critical, consider the $0.05 USD or lower similar devices but not as good as this TI device from Socay (Shenzhen, CN). Also suggest to place an EMI filter in series with the USB data lines - Kingcore (Taiwan is < $ 0.10 USD for USB 2.0 devices). Somewhere in this forum, have posted the full p/n and contact details for each such vendor.

f) does the USB hub truly not require any xtal loading caps on pins 2 & 3? Please confirm this. Often caps are required on each leg of a crystal.

The preaching may continue later on but need to review some internal paperwork for now...do post your updates after testing of the above suggestions.

[Kevin Jordan]

First thing to note is that the RESET supervisor is open drain. With your current setup, power up and check the voltage on #RESET of the CPU line / pin 1 of U12.

Pin 1 on U12 is 3.27V

Then hard short pin 1 of U12 to GROUND and release after a few seconds. Try your XTAG3 scan again after this procedure.

This did not fix it. Still nothing showing up when I list-devices in xflash

1) What is the measured voltage for your 1v0 rail? What are the exact stuffed values for R3 & R4 (Vfb resistors)? This buck regulator is marked as NRND.

Measured voltages on:
1v rail: 2.87v !!!!
3.3v rail: 3.304V
5.0 rail: 5.04V

Ok, without a XMOS chip placed on another board, I'm getting 0.994V on the 1V rail. I guess I didn't think to test the 1v rail after the XMOS QFN IC was placed. I'm going to look for bridges. I measure 4.9 ohms between 1v and 3.3v rails on this board and 8k Ohm between 1v and 3.3v on a board without this chip placed.

I'm going to see about fixing this issue and I'll update you shortly. Thanks for your help!

[Kevin Jordan]

1) What is the measured voltage for your 1v0 rail? What are the exact stuffed values for R3 & R4 (Vfb resistors)? This buck regulator is marked as NRND.

I fixed a short between pins on the QFN, now I'm seeing 0.987V on the 1v rail. I re-tried shorting the U12 pin 1 to ground, and then xflash --list-devices, and still no show on the device list.

2) As a general rule, the voltage sequencing is very important to prevent possible latch up of the CPU. The guidelines in the datasheet recommend:

a) monitor the +3v3 rail with a voltage supervisor -> once this threshold is met, use the PG signal from this 3v3 supervisor to enable the +1v0 rail.
b) monitor the +1v0 rail with a voltage supervisor -> once this threshold is met, use the PG signal from this +1v0 supervisor to release the #RESET of the CPU.

For the above reasons, suggest to rework the +3v3 voltage supervisor (U12) to enable the +1v0 buck regulator (not the #RESET signal).

Then add another +1v0 supervisor that can trigger @ 0.9v to release the #RESET signal.

I can try this on my next spin up of this board. I tried following the exact schematics from the Dev Board.

You may have some luck as-is with the design but the above is highly recommended. In the mean time, do check if the #RESET line is truly HIGH after a power up or is it still LOW which would then halt any activity of the XTAG3 (JTAG) traffic.

I have an LED and measured the voltage, the RESET Line is high. I'm wondering if I let the magic smoke out of the IC with having 2.8v go to the 1v pins.

c) Pin 61 (CPU middle paddle connection) must be mated with GROUND. Often, this is a root cause of such issues as observed from a long list of OEM design reviews. Would not hurt to throw some hot air onto the CPU to guarantee the middle belly pad is truly grounded.

d) Remove R46R26 as it is not required, R41 serves this PU purpose for #CS of the QSPI flash device.

Did both of these things. Thanks for noticing R26 isn't required.

e) not related but preaching hat is on - there MUST be some form of ESD protection on the USB lines else you will face returns due to Stephen King storyline events that will damage your widget. From memory, we found that the TI ESDS312 is the best in the marketplace as of this writing. If cost is really critical, consider the $0.05 USD or lower similar devices but not as good as this TI device from Socay (Shenzhen, CN). Also suggest to place an EMI filter in series with the USB data lines - Kingcore (Taiwan is < $ 0.10 USD for USB 2.0 devices). Somewhere in this forum, have posted the full p/n and contact details for each such vendor.

Thanks for the suggestion, I'll add these to the next spin of the board.

f) does the USB hub truly not require any xtal loading caps on pins 2 & 3? Please confirm this. Often caps are required on each leg of a crystal.

I'll check on this. I messed up the pins of the crystal, so right now, it's flipped over and deadbugged with a couple wires connecting to it. The USB hub works playing music to the USB sound card. This will be fixed on the next run and I'll check on the XTAL loading caps.


I'm still not able to show the device in xflash. However, when I ground the reset, let go, then try to connect, I notice activity on the USB hub for the port connected to the XMOS USB. It does not show activity when I ground and release the pin, only when I try to list-devices. This leads me to believe I haven't completely killed this chip.

My next step is going to be removing this IC and trying a fresh one.