USB CDC device cant connect after soft reset

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
Post Reply
tilde
Member++
Posts: 22
Joined: Fri Nov 07, 2014 9:03 am

USB CDC device cant connect after soft reset

Post by tilde »

Hello,

I upgrading our hardware(XE216-512_TQ128) by USB CDC device, and when programming is done I made a soft reset by a func:
device_reboot_aux () (function is available in the end of message).

The problem is:

- After reboot I cant connect to cdc serial device(e.g. Hyper Terminal, or by other own made serial application). I m using Windows7.
- I can see the device in device managger, and by messages from here, it is working properly, but not works with real Hyper Terminal.
(I have a composite device, Usb Audio + CDC + WebUsb, and other devices working properly after soft reset.)

There are two solutions:

- Unplug/ Replug usb device
- Reinstall driver (USBSER.SYS) from Task managger. (This works without manual unplug/replug)

I think the problem is with driver. Maybe during soft reset, the device is not correctly unplugged/plugged. Can I somehow connect/reconnect the usb on xmos device by firmware?

Code: Select all

void device_reboot_aux(void)
{
    unsigned int pllVal;
    unsigned int localTileId = get_local_tile_id();
    unsigned int tileId;
    unsigned int tileArrayLength;
    unsigned int i;

    /* Find size of tile array - note in future tools versions this will be available from platform.h */
    asm volatile ("ldc %0, tile.globound":"=r"(tileArrayLength));

    /* Reset all remote tiles */
    for(i = 0; i< tileArrayLength; i++)
    {
        /* Cannot cast tileref to unsigned! */
        tileId = get_tile_id(tile[i]);

        /* Do not reboot local tile yet! */
        if(localTileId != tileId)
        {
            read_sswitch_reg(tileId, 6, pllVal);
            pllVal &= PLL_MASK;
            write_sswitch_reg_no_ack(tileId, 6, pllVal);
        }
    }

    /* Finally reboot this tile! */
    read_sswitch_reg(localTileId, 6, pllVal);
    pllVal &= PLL_MASK;
    write_sswitch_reg_no_ack(localTileId, 6, pllVal);

    while(1);
}


With kind regards
Tilde
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. No direct experience with this but found the following:

https://www.xcore.com/viewtopic.php?t=3539

#include <xs1.h>
void chipReset(void) {
unsigned x;
read_sswitch_reg(get_core_id(), 6, x);
write_sswitch_reg(get_core_id(), 6, x);
}

In a dual tile device like XS1-L16, or XU232, a soft reset should be issued for each tile separately in proper sequence. You should first reset the other node, before resetting your own node.

So can you try the same? Please post your results. Also, have you attempted to run the XMOS basic USB CDC IP and apply the same soft reset? What are the results?

BTW - Are the format tags working correctly for your browser? Locally on Firefox, can see the format tags which is not correct. For example the above quote should be in italics. Just curious.
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Hi.

It looks to me like tilde's function device_reboot_aux() is indeed doing a reboot on the other "nodes" (tiles) before rebooting the local tile. What we have found is the device reboot function doesn't seem to work right when you are running under xrun (e.g. in the run or debug mode in the IDE). Just wondering if that's how it's working for you.
tilde
Member++
Posts: 22
Joined: Fri Nov 07, 2014 9:03 am

Post by tilde »

[quote]In a dual tile device like XS1-L16, or XU232, a soft reset should be issued for each tile separately in proper sequence. You should first reset the other node, before resetting your own node. So can you try the same? Please post your results.[/quote]

My code resets in first step the other tile, and after that own tile. I think it is OK.

[quote]Also, have you attempted to run the XMOS basic USB CDC IP and apply the same soft reset? What are the results?[/quote]

I test soft reset on basic CDC usb app (no composite device), and now after soft reset I can reconnect to serial port without usb unplug/replug. So the problem is with my composite device. I have to look it up. :)

I have to follow only one thing. I must disconnect cdc serial link in terminal app before soft reset. When I forgot it, than after reset I cant communicate over cdc serial (only unplug/replug usb helps). I can do it on software side, so no problem.

[quote]What we have found is the device reboot function doesn't seem to work right when you are running under xrun (e.g. in the run or debug mode in the IDE). Just wondering if that's how it's working for you.
[/quote]

I testing it with application which is running from flash. After soft reset the xrun cant respond, too.

[quote]BTW - Are the format tags working correctly for your browser? Locally on Firefox, can see the format tags which is not correct. For example the above quote should be in italics. Just curious.[/quote]

Format tags don`t works for me, I cant see them. Not under Firefox, or Chrome.
With kind regards
Tilde
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Yeah, looks like the formatting tags are broken.
tilde
Member++
Posts: 22
Joined: Fri Nov 07, 2014 9:03 am

Post by tilde »

Under Win10, soft reset on device with usb composite device of (audio class 2, HID, WebUsb, CDC) works correctly. :) So it is time to forget Win7.

p.s. when I disable HID part of mine device, than CDC soft reset works under win7, too. This is weird.
With kind regards
Tilde
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Interesting.

From my understanding, both HID and CDC drivers are developed by Microsoft and OS supplied. The INF files just marry the VID & PID IDs through this file to attach the OS supplied drivers. That is, the OS drivers should be rock solid so we can rule out the OS as the fault.

You could review the TASK VIEWER of your IP to see what happens WITH and WITHOUT HID IP inside your firmware. That is, is there a possibility that the cores do not have enough bandwidth to support all what is going on for proper USB support?

See here:
https://www.xmos.com/developer/publishe ... dio-readme

If my memory is correct, you are limited to the bandwidth usage of each core / tile so that you do not break the USB IP timing.

Also, in reviewing another OEM's firmware source code, found that they had left active some code runs in the audio IP that was pinging phantom I2C devices that are not present on their custom PCB. This was leading to many retries in the XMOS IP that consumed bandwidth due to blocking code and resulted in many USB faults that they chased for months. The simple remedy was to remove / mask out the calls to these non existent I2C devices. Please review the same on your widget. Another possible quick work around is to reduce the I2C retry from 2000 (believe this was the value) to perhaps 5-10 or less and check the results again on your Win7 box.

Assuming that the Win7 testing is on the same box as the Win10 testing?

Do run the TDD.EXE from TheSycon which is a USB descriptor validation tool that also raised assorted errors with the XMOS IP. How does your IP score against this test tool ?

Curious on your results of all of the above ideas.

One more thing...which ports are being used on your box during the Win7 testing? Win10 testing? USB 2.0 (black insulator) or USB 3.x (blue insulator)? Is the physical USB port being used residing on a downstream internal hub controller? If yes, try the test again on a direct USB port or if possible a different box with Win7.

How about Win7 emulation under Windows 10? Does that change anything? You could try a VM here as a suggestion.

How long is the USB cable? Is it a branded and quality cable? Try a USB 2.0 HS marked cable (often will be marked on the sleeve) and with ferrites. Just a test. We recently had some produced in Taiwan and the quality does vary with the cost of the cable. Try a short cable if possible.
tilde
Member++
Posts: 22
Joined: Fri Nov 07, 2014 9:03 am

Post by tilde »

TDD.EXE - was a big help for me. This shows me some errors in usb descriptors: (Before I use another usb analyzer, but that cant show any error. :( )
- audio class 1.0: param wTotallength in AudioControl interface header descriptor was wrong
- in cdc descriptor I use, too big wMaxPacketSize for data endpoints. (Usb Full speed supports only 64 byte).

It is nice, but that cant help me with serial port. It help me solve another problem. From now usb audio class 1, works under Win10, too. Win10 looks more sensitive then Win7 in descriptor errors.

- Task viewer cant show any difference between system with and without HID.

- Usb cable, ports test: Both computers (Win7 and Win10) has only USB3.0 ports. Cables are OK. So, I think it is not a problem.

While I m testing, I find another problems, too. So now I m working on them.
With kind regards
Tilde
tilde
Member++
Posts: 22
Joined: Fri Nov 07, 2014 9:03 am

Post by tilde »

Thank you for help. I must close this topic. On win10 the application is rock solid. The problem is available only on Win7, but we dont need any more support for win7. :)
With kind regards
Tilde
Post Reply