ColdFire/68K Microcontrollers and ProcessorsのトピックRe: 5474 USB GET_DESCRIPTOR handler

5474 USB GET_DESCRIPTOR handler

MH — Fri, 07 Apr 2006 23:34:00 GMT

After the USB has been reset (RSTSTOP interrupt received) I receive the SETUP interrupt. I decode bmRequestType (0x80), bRequest (0x06) and wValue (0x0100) to determine that a device descriptor has been requested. I then load the descriptor RAM control register (DRAMCR) with the address of the descriptor and size and then set the START bit. (The descriptor RAM has already been initialised and I have confirmed that it holds the correct values). The problem is that the BSY bit in DRAMCR does not clear.

Any ideas on where I may have gone wrong?

Thanks,

Malcolm

(MCF5474 with date code QAQ0525 on a 5474LITE board)

Re: 5474 USB GET_DESCRIPTOR handler

mnorman — Sat, 08 Apr 2006 03:29:45 GMT

Did you set the USBCR[RAMEN] bit after the RSTSTOP interrupt occured? Here are some code snippets that might help.

Init (prior to bus reset):

/* Clear USBCR_RAMEN to allow access to descriptor RAM */
MCF_USB_USBCR &= ~MCF_USB_USBCR_RAMEN;

/* DRAMCR[DADR] = 0 */
MCF_USB_DRAMCR = 0x00000000;

    /* Load the Descriptor RAM with the descriptors */
    for (i = 0; i < DescSize; i++)
        MCF_USB_DRAMDR = (0 | pDevDesc[i]);

In the RSTSTOP interrupt handler:

/* Validate Descriptor RAM */
MCF_USB_USBCR |= MCF_USB_USBCR_RAMEN;

In the SETUP interrupt handler:

    switch (bRequest)
    {
        /* GET_DESCRIPTOR */
    case 0x6:
        switch (wValueUpper)
        {
            /* Device Descriptor */
        case 0x1:
            /* DADR = 0 for Device Descriptor */
            MCF_USB_DRAMCR = (0
                | wLength << 16
                | iDevDesc);

MCF_USB_DRAMCR |= MCF_USB_DRAMCR_START;
break;

...

-mn

Re: 5474 USB GET_DESCRIPTOR handler

MH — Mon, 10 Apr 2006 21:14:40 GMT

Yes, I set RAMEN after the RSTSTOP interrupt. I'm doing everything you show in your snippets

Initially I only have the RSTSTOP, SETUP and CNTOVR interrupts unmasked and I keep a copy of USBISR and USBAISR when I service the interrupts to aid in debugging.

I found an error in the way I was clearing the USBAISR interrupts. I was writing a one to the relevant bit in the same way as clearing interrupts in USBISR. Now I am writing a zero to the relevant bit I am getting something more understandable but DRAMCR[BSY] still remains set to one.

Now when I plug in the USB cable I get a RSTSTOP interrupt that I respond to followed by a request for the device descriptor that I respond to. I then get repeated CNTOVR and IN interrupts indicated in USBAISR (I've enabled the CNTOVR irq while debugging). The counter that is overflowing is PPCNT (CNTOVR = 1). After about 5 seconds I get a second RSTSTOP interrupt followed by a request for the device descriptor followed by repeated CNTOVR and IN interrupts. After another 5 seconds this is repeated once more before the host announces that the USB device was not recognised. As far as I can tell, DRAMCR[BSY] remains high throughout. Can you suggest anything else to check?

It's a shame Freescale don't publish any sample code from which to build on.

Regards,

Malcolm

Message Edited by MH on 04-10-200612:01 PM

Re: 5474 USB GET_DESCRIPTOR handler

MH — Tue, 11 Apr 2006 18:33:10 GMT

The manual isn't clear about how much of the control transaction required for the GET_DESCRIPTOR request is performed automatically. For example, the USB spec states that "The function receiving a SETUP must accept the SETUP data and respond with ACK.".

Can I assume that the USB module responds with ACK automatically since I can't see a way of initiating an ACK response myself?

Is it correct that the only response required to a request for the device descriptor is to set up the start address and descriptor size in DRAMCR followed by setting DRAMCR[START]? This is what is shown in the code snippets above but I don't know what has been omitted from the example. When DRAMCR[START] is set, DRAMCR[BSY] goes high. Should the BSY bit clear a short time later to indicate that the GET_DESCRIPTOR handler has finished without any further action from the firmware? If, as in my case, the BSY bit does not clear, what are the likely causes (RAMEN is set)?

Thank you.

Re: 5474 USB GET_DESCRIPTOR handler

mnorman — Wed, 12 Apr 2006 00:57:23 GMT

You will also want to make sure that the EP0 FIFO is setup. I've attached a snapshot of a USB driver for this device controller. This is a work in progress (there are still some to-dos) but it is functional. An updated version of this driver with some sample applications is in the works and will be posted with the other sample code.

Re: 5474 USB GET_DESCRIPTOR handler

MH — Tue, 18 Apr 2006 20:09:07 GMT

Thank you for the usb example. I am working through it and have one question so far. When writing a byte to the USB Endpoint n FIFO Data Register (EPnFDR), is it written to EPnFDR[31..24] or to EPnFDR[7..0] ?

Thanks,

Malcolm

Re: 5474 USB GET_DESCRIPTOR handler

mnorman — Tue, 18 Apr 2006 23:48:29 GMT

To write a byte, you just address the register as an 8-bit address. For example, EP0 FIFO data register (address MBAR + 0xB450) could be accessed as follows in C (assuming __MBAR is defined as a byte array that points to the start of the internal module memory map):

uint8 data8 = 0xAB;
uint16 data16 = 0xABCD;
uint32 data32 = 0xABCD0123;

*(uint8*)(&__MBAR[0x00B450]) = data8;
*(uint16*)(&__MBAR[0x00B450]) = data16;
*(uint32*)(&__MBAR[0x00B450]) = data32;

Internally, the byte accesses will use the upper byte lane (31:24) to transfer the data for byte accesses, but you don't really need to worry about that. Just access it at the base address no matter what the transfer size is.

Note that the C header files provide macros for the different accesses, so the above could be:

MCF_USB_EP0FDR_8 = data8;
MCF_USB_EP0FDR_16 = data16;
MCF_USB_EP0FDR_32 = data32;

Message Edited by mnorman on 04-19-2006 01:45 PM

Re: 5474 USB GET_DESCRIPTOR handler

MH — Wed, 19 Apr 2006 00:24:12 GMT

Thank you for the information. The C header files I downloaded didn't have the 8-bit access macro so I'll check to see if I can find newer versions.

Anyway, I am now making progress. The host is reading the device descriptor, the configuration descriptor, the language descriptor and the product descriptor. It then pops up a "found new hardware" balloon containing the product descriptor and asks for the driver.

Regards,

Malcolm

Re: 5474 USB GET_DESCRIPTOR handler

DavidHearn — Thu, 18 Jan 2007 04:23:03 GMT

Same here, the files in the usb.zip file don't have the _8, _16 or _32 bit macros, nor do the CodeWarrior ones (which are in the format MCF_USB_EPnXXX(y) rather than MCF_USB_EPXXX(y) in the provided code.

I've started modifying the code to work with the CodeWarrior headers, but not yet worked out what I need to do with the _8,_16 and_32 ones (probably straightforward).

However - if someone else had done these macros (or have an updated usb.zip file as suggested when usb.zip was posted) that would be great.

Thanks

David