topic Re: USB connection stuck in usb_host_start_transaction in ColdFire/68K Microcontrollers and Processors

USB connection stuck in usb_host_start_transaction

Frelon — Fri, 28 Nov 2008 21:43:31 GMT

I use the CMX routines downloaded from Freescale Web Site, a MCF52211 and CodeWarrior 7.0. I have 2 important issues related to the usb_host_start_transaction() function:

1- There is a USB key that can not be read/write or initialized at all. It is a standard USB key (1GB) and it is working correctly on my PC (Windows XP);

2- During a transfer (read or write), when I remove a USB key, any key, the action is well supported most of the time, but some time not (1/20 with some keys, problematic each time for few keys);

The common thing with these 2 problems is that the ColdFire is waiting infinitely in the following loop of usb_host_start_transaction() :

while((MCF_USB_INT_STAT & (MCF_USB_INT_STAT_TOK_DNE | MCF_USB_INT_STAT_STALL | MCF_USB_INT_STAT_ERROR)) ==0)

{

if (MCF_USB_INT_STAT & MCF_USB_INT_STAT_USB_RST)

{

evt_disconnect();

tr_error=tre_disconnected;

return((hcc_u16)-1u);

}

I tried to resolve the problem by checking the following post:

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=4944&query.id=100893#M4944

and

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=5182&query.id=100901#M5182

but without success.

Note: for point #1, I also tried the same USB key on a M52210DEMO board with original Freescale code on it to make sure it was not specific to my software project, but the same problem happen. It freezes after "Mass-storage driver started”.

Did someone got that problem too and overcome it?

Frelon

Re: USB connection stuck in usb_host_start_transaction

RichTestardi — Sat, 29 Nov 2008 01:42:24 GMT

My experience has been that when you get "stuck" waiting for TOK_DNE, you're not actually stuck at all, but in an infinite (hardware) retry loop where the device is returning infinite NAKs. If you turn of hardware retries (RETRY_DIS = 1) then you might be able to see the NAKs (you'll get a TOK_DNE for each) to confirm it... Or if you put on a USB analyzer, that's even easier yet!

What I found was that many keys depend on a very specific (certainly against the spirit of the SBC standard) order of commands during initialization, including magic sequences of Inquiry, Test Unit Ready, Request Sense, and Read Capacity. Apparently they all expect the order that Windows happens to send, and if you do a different order, things get confused.

We eventually got every key we had (about 20-30, including card readers and multi-LUN devices, not to mention a half dozen MST-capable cameras) working with our initialization sequence, which is below if it helps. The API is for our custom USB host/device driver (source available in skeleton.zip at http://www.cpustick.com/downloads.htm), but I believe the command sequence should be obvious from it if you want to try and mimic it. (I definitely found keys CMX could not talk to for this reason, when attempting to isolate the bugs and going back and forth between drivers.)

Code:

        // set interface        usb_setup(0, SETUP_TYPE_STANDARD, SETUP_RECIP_INTERFACE, 0x0b, 0, 0, 0, &setup);        rv = usb_control_transfer(&setup, NULL, 0);        //assert(rv == 0);        // get max lun        usb_setup(1, SETUP_TYPE_CLASS, SETUP_RECIP_INTERFACE, 0xfe, 0, 0, sizeof(max_lun), &setup);        max_rv = usb_control_transfer(&setup, &max_lun, sizeof(max_lun));        //assert(max_rv == 1 && max == 0);                scsi_lun = 0;XXX_NEXTLUN_XXX:                // inquiry        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x12;  // inquiry        cdb[4] = 36;        rv = scsi_bulk_transfer(1, cdb, 6, buf, 36);        if (rv < 0) {            return rv;        }        assert(rv == 36);                // test unit ready        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x00;  // test unit ready        rv = scsi_bulk_transfer(0, cdb, 6, NULL, 0);                // request sense        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x03;  // request sense        cdb[4] = 18;        rv = scsi_bulk_transfer(1, cdb, 6, buf, 18);        if (rv < 0) {            return rv;        }        assert(rv);                // test unit ready        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x00;  // test unit ready        rv = scsi_bulk_transfer(0, cdb, 6, NULL, 0);        if (rv < 0 && max_rv == 1 && scsi_lun < max_lun) {            scsi_lun++;            goto XXX_NEXTLUN_XXX;        }        if (rv < 0) {            return rv;        }                    // read format capacities        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x23;  // read format capacities        cdb[8] = sizeof(buf);        rv = scsi_bulk_transfer(1, cdb, 12, buf, sizeof(buf));        assert(rv);                // read capacity        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x25;  // read capacity        rv = scsi_bulk_transfer(1, cdb, 10, buf, 8);        assert(rv == 8);                // request sense        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x03;  // request sense        cdb[4] = 18;        rv = scsi_bulk_transfer(1, cdb, 6, buf, 18);        assert(rv);        // test unit ready        memset(cdb, 0, sizeof(cdb));        cdb[0] = 0x00;  // test unit ready        rv = scsi_bulk_transfer(0, cdb, 6, NULL, 0);

Re: USB connection stuck in usb_host_start_transaction

Frelon — Sat, 29 Nov 2008 06:00:20 GMT

Hi Rich, thank you for your answer, it gives us new ideas of sequence to use to be more compatible. Also I will check if there is some information about the order that Windows sends these commands.

Frelon

Fixed CMX Host reliability and lockup issues.

DMV — Wed, 21 Jul 2010 06:55:12 GMT

Simple Change:

From

'static void demo_process(void)

...

if (tr_error != tre_none) demo_info.state=DMST_BADDEV;

..."

'static void demo_process(void)

...

      if (tr_error != tre_none)
      {
          //Reset Device
          demo_info.nlun = DMST_NODEV;
          demo_info.state =DMST_NODEV;
          //Reset USB
          host_init();
          scsi_init();
      }

..."

Background:

------------------

Expanded error reporting of "if (tr_error != tre_none) " to report all errors

/* Error codes. */
typedef enum {
tre_none=0,
tre_not_running, /* host operation disabled */
tre_no_device,    /* no device connected */
tre_disconnected, /* device has been disconnected */
tre_stall,        /* endpoint halted by device*/
tre_data_error,   /* communicatin error (CRC, etc...)*/
tre_silent,       /* device returned no handshake at all */
tre_no_ep         /* endpoint not configured */
} tr_error_t;

Found CMX errors and lockups when

1). With flash drive repeat wiggle/ removal / re insert, causes tre_data_error "Communication error (CRC, etc...)" then gets stuck in while(MCF_USB_CTL & MCF_USB_CTL_TXDSUSPEND_TOKBUSY) (DemoJM & Custom PCB)

2). No Drive, using internal regulator (touch usb connector D+/D- Lines) causes tre_data_error "Communication error (CRC, etc...)" then gets stuck in long stack_size(byte pattern) (Custom PCB)

David

david@designfeats.com

Perth, Australia

Re: Fixed CMX Host reliability and lockup issues.

DMV — Wed, 16 Feb 2011 09:17:27 GMT

See Post

https://community.freescale.com/message/78726#78726