AN00136

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Elmodriver
Junior Member
Posts: 5
Joined: Tue Oct 06, 2020 8:03 pm

AN00136

Postby Elmodriver » Thu Oct 08, 2020 3:58 am

I am trying to implement a data transfer mechanism between an Xmos based phased array application. The device is onboard a small mobile device, whose linux based main processor is best suited to receive our phase array info via USB. I am new to USB. I can't seem to make the transfer work, and could use advice.

Requirement - transfer tables of 40000 bytes from xmos to host. Optionally transfer like-sized files from host to Xmos.

environment - XCORE-2000 driven by window 10 via xTIMEcomposer, as downloaded from XMOS recently, and Linux server. I am using libusb 3.1.2.

Narrative - Initially I used AN00125 as a framework, and found that AN00136 more simply match my needs as a framework for the signal processing api. I also tried custom api's as inspired by various internet tutorials. On the linux development host I tried several examples from the internet, the host linux 64 bit source from AN00136, as well as a simple python example from pyusb.

Problems:
1. The PID in the XMOS code is sent as 0x001B but always arrives at the host as 0xF7D4, no matter which xmos code or host API I use.

2. The read never works, usually failing with a time out, or with the read return code saying success but no data transferred. The write times out intermittantly, and I cannot verify that the write, when it succeeds, actually transfers data, because I cannot read it back. As a test I wrote to the XCORE-200 onboard LEDS reacting to expected write data, and while the led debugging technique worked, they never showed a write that matched what was to be sent.
I reviewed prior posts on problems with AN00136 and tried each without success, with one exception, and that is a post where lib-usb 3.0.0 didnt, but 3.1.0 did. A fix was scheduled for 3.1.2, and the code was listed, but not where the fix was to be applied. The post indicate that the fix was included in 3.1.2. I am using 3.1.2, and it isn't working. XMOS doesn't seem to have legacy libusb's and I don't know where else to look.

The project needs to replace a Measurement Computing USB1808 used for prototype development, which transfer data to the linux host, at 48 megabytes/second. I need to do signal processing on a mobile device requiring the multiple cores of the XMOS, also the USB1808 is much too large for the mobile device. The signal processing app was successfully ported to the XMOS, and functions, as verified with LEDs as above. My current efforts do not involve the USB yet because I want clear indication that the USB operates properly before I morph it into the phased array app.

I ran lsusb -v with both the USB1808 and the XCORE-200 USB cables plugged in, and the descriptors for both units were the same except for vid/pid and fields ignored by the transfer type
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed Oct 14, 2020 10:47 am

Hi. Start with validation of your hardware and the operation of the USB hid mouse IP.

See here for some ideas. Test on windows first and then on your Linux box.

viewtopic.php?f=26&p=38132

Do you see the mouse pointer move in the square pattern repeatedly till the board is stopped?

If not, test the same demo on your Xmos official kit.

This IP example will confirm high speed USB traffic being generated by your PCBA.
Elmodriver
Junior Member
Posts: 5
Joined: Tue Oct 06, 2020 8:03 pm

Postby Elmodriver » Sat Oct 17, 2020 1:30 am

One of my problems is that when the XMOS sends the device descriptor the PID (not HID)(" product ID") is 0x001b, but when received by the host it is 0xf7D4, which means I must change what the find device by ID function looks for, or the device isn't found. Since it is shifted into a word with the VID ("vendor ID") I don't know how to put a debug value watch on it. I suspect that the same type of corruption of the control transfer request is why the read always fails. BTW, is there anybody out there that has successfully run the code in AN00136 using lib_usb 3.1.2 using the host bulk_transfer code on linux? I have to use a linux host because the ultimate use runs linux, and can't run windows. The compiled version doesn't work on UBUNTU 19.04, It seems to if I compile it and use the compiled code. If I could see how someone else did it, maybe I could make the same thing work for me.

I have followed your input to the thread labeled "lib_usb 3.1.1 problem?" which seems to delinate the same problem. I see that ross indicated a fix that would be in usb_lib 3.1.2. I didn't see a post that deliniated that the fix has been tested. There is code that shows the fix, which I could apply if I knew where the fix goes. I didn't see that in the code description.

Elmodriver ( I am an electric auto nut)
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Oct 17, 2020 6:12 pm

What was the result of testing the high speed mouse IP example on your PCBA?
Elmodriver
Junior Member
Posts: 5
Joined: Tue Oct 06, 2020 8:03 pm

Postby Elmodriver » Sat Oct 17, 2020 9:50 pm

I installed and compiled and downloaded AN00129. I plugged the host usb into the USB port on the xCORE-200. I ran lsusb on the host and it did not see the XMOS device. I plugged the host usb into the XMOS I2V dongle on the xCOREW-200, ran lsusb, and the host DID see the XMOS device. I plugged the mouse into the host and it worked. I unplugged the host from the I2V and the mouse still worked. I don't know how to force the host to use the xmos version of usb for the dynamic mouse action.
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sun Oct 18, 2020 9:57 am

Ok. The XMOS USB high speed mouse example is a HID device. This means that nothing is required to operate the IP other than to plug it in to your host PC. Just like a HID keyboard, plug in and use.

Please find another PC and test again with this mouse IP on your PCBA. Does it work on another PC?

Try with a shorter and different usb cable than what you are using now. If possible, a brand name usb cable.

Try on a windows based host PC like a laptop or another.

If you are unable to see this mouse IP being detected in your tests then try the same mouse IP on an Xmos official kit. Does the XMOS official kit work with your host PC and USB cable? It must work.

Post the relevant parts of your Xmos schematic and pcb layout for a quick review. Based on the details do far, there are signal integrity issues.

How many layers is your custom PCB? Ideally should be 4 layers or more for best results.

Are the usb traces impedance controlled at 90 ohms? A good pcb shop will be able to confirm this upon demand.

From our review of many XMOS designs to date, the CPU is quite resilient for testing this mouse IP so the issue may be some other simple error in your custom PCBA.

Do post the schematic and pcb layout of the XMOS CPU, the usb interconnect and power supply for this review.
Elmodriver
Junior Member
Posts: 5
Joined: Tue Oct 06, 2020 8:03 pm

Postby Elmodriver » Sun Oct 18, 2020 3:06 pm

I am using XMOS official kit for EVERYTHING! Two different XCORE-200-EXPLORER boards and attachment card, AN00125, AN00136, AN00129 software unmodified. I want the official stuff to work before I send out the target board for fab. All with the same results: The host recognizes an XMOS device during discovery. In all cases the PID at the XMOS for the device is 0X0001b, and at the host (windows and linux) the PID is 0xF7D4, so when the host tries to open as specific PID/VID, it isn't found. The mouse is NOT active in any of the cases, short wires, long wires. When I modify AN00136 and AN125 code to look for PID 0xF7D4, the app fails during read. Can you find ANYONE who has the out-of-the-box code and XCORE-200-EXPLORE using AN00136 working in the last few years? In the case of AN00125 and AN00136. Note that the xmos documentation refers to using the USB port on the XCORE-200, which doesn't work in any of these circumstances, but when I use the debugging port for the usb outlet, the device descriptiors, however invalid, are transmitted and discovered.
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Mon Oct 19, 2020 11:00 am

Very odd behavior. Confident that we have it working in the lab on the same kit and also on custom PCBs from other developers. However will confirm again once we dig out the respective kit. Let us see how busy the day is and will check again.

Post the compiled .xe file from the unmodified Xmos hid mouse IP that you are using. Be sure that the target kit is selected for the compiler.

Download and run this following tool on your windows box and share the results if the tool can index the usb device:

https://www.thesycon.de/eng/usb_descriptordumper.shtml

The tool will check the integrity of the USB descriptors.

Please post the detailed log from your Linux box for the dmesg command so we can see the output from your mouse IP.

One major concern is that the XMOS CPU is plagued with an in-rush current issue. That is, the USB cable being an inductive load will cause an in-rush voltage spike that can damage the XMOS cpu's USB PHY. See the reference to this errata inside all current CPU datasheets. For this reason, a special filter must be present on the Vbus rail. However, not sure if the kits your are using have this filter or not. Please review the schematic and your pcb layout of the kit.

Personally my opinion is that the filter is a bare minimum fix, rather an active device like a USB load switch should be used. For example, we deploy the AP2331 from Diodes inc. with success on volumes of our medical devices we build. Zero failures. Has many nice features to protect the usb downstream controller from damage.

Please do not submit your custom PCBA till these issues are resolved and we can agree on any necessary tweaks.

It is quite possible that Xmos CPU is damaged with respect to the usb interface since the default Xmos mouse IP is not working but let us review the same to share the latest report.

Which compiler tool version are you using?
User avatar
mon2
XCore Legend
Posts: 1831
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Mon Oct 19, 2020 9:53 pm

Hi. Invested a few hours on this and suspecting that my past experience was with the XMOS USB slice kit and not with the XCORE-200 Explorer kit. However, being confident that we have tested the XMOS HID Mouse IP AN00129 on the XE216 target CPU (custom PCBA) with success, proceeded to test with the Explorer kit.

Summary, the XMOS HID Mouse IP works fine on the XCORE-200 Explorer kit (XtimeComposer 14.4.0).

Please review and study the attached procedure and consider to use the posted .XE file onto your kit.

A key takeaway here is that the issue may be that the USB POWER port is keeping the kit powered at all times, rather than Vbus from the port that is spitting out the data from the mouse IP. For this reason, power down and short the pads @ R51. See attached.

After this solder short, use ONLY the USB connector @ J5 (do not use J16 as the Vbus rails are now being OR'd together).

Do post your results.

xmos_usb_mod.jpg
XMOS_HID_Mouse_procedure.zip
You do not have the required permissions to view the files attached to this post.
Elmodriver
Junior Member
Posts: 5
Joined: Tue Oct 06, 2020 8:03 pm

Postby Elmodriver » Wed Oct 21, 2020 10:58 pm

I made the hardware change, and did the usb descriptor output from XMOS_USB_MOD_JPG, the text of which is below. I downloaded the .xe you send and used xrun to download it to the XCORE-200. The VID is still wrong, it still doesn't work when plugged into the #5 USB port of the XCORE-200, it still does work when plugged into the download dongle card, the mouse continues not to work under the circumstance it didn't work above.

I see that the VID is still wrong, notice the 64 vx 512 length errors in the list of attributes below. Using AN00136, my custom code, and AN125 where I had that error I changed the length on the xmos code to 512 and it still didn't work. So please please please what am I doing wrong?

forum_response.rtf
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: No registered users and 8 guests