ARM7: LPC2148 & USB communication

Got finally!!!
Thanks for your constant support!
By implementing Bettrick's method, I got the Get_descriptor command with length field 18.
Challenge - Still not getting Get_descriptor for configuration descriptor. Can it be problem of Vendor id or product id?
I am not using Keil board. It's board designed by local company.

Got finally!!!
Thanks for your constant support!
By implementing Bettrick's method, I got the Get_descriptor command with length field 18.
Challenge - Still not getting Get_descriptor for configuration descriptor. Can it be problem of Vendor id or product id?
I am not using Keil board. It's board designed by local company.

Actually I am using LPC2148 CPU module designed by local company. Can I use vendor id and product id by Keil?

> Can I use vendor id and product id by Keil?

Unless the Vendor/Product ID (VID/PID) conflict with other devices connected to your PC, you can use any VID/PID on your PC for development. Unique official VID/PID is required when you release your product, so that it doesn't conflict with others on your customer's PC.
I often use VID = 0xFFF0 - 0xFFFF for development. USB.org has not assigned these range of VID yet, then it should not conflict with existing USB devices.

Tsuneo

This is given in USB in a nutshell.
Normally when something is wrong with a descriptor or how it is being sent, the host will attempt to read it three times with long pauses in between requests. After the third attempt, the host gives up reporting an error with your device.
I am getting Get_descriptor 3 times and then nothing happens.
But if I can send 8 bytes successfully then I think 18 bytes also would have gone succesfully.
And I have already shown my device descriptor before. And t seems to be fine.
What else can be the problem?

Still not getting Get_descriptor command for configuration descriptor.
But getting it for device descriptor three times. What can be the problem?

Most of points have been discussed already. I don't think of any more.
If you would have a hardware analyzer, you could get more detailed sign to focus on the firmware bug...

Do you have any account on a server to share your code?
Post your code to the sharing server so that we can look into it.
If it can, I'll run your code on my LPC2148 board (IAR or Olimex), and monitor it with a hardware analyzer.

Tsuneo

If it can, I'll run your code on my LPC2148 board (IAR or Olimex), and monitor it with a hardware analyzer.

you have a good soul!

I have sent my code on your yahoo account which I got from LPC2000 group. Problem still continues......

> I have sent my code on your yahoo account which I got from LPC2000 group.

I don't see the yahoo mail at all. The account is held just to post to LPC2000.
Until you noticed to me on above post, I wasn't aware of your mail ;-)
Fortunately, yahoo server still kept your mail.



Now, your code is running on my Olimex LPC2148 board.
The outline of the trace on a hardware analyzer is as follows

- Bus Reset
- Get_Descriptor( Device ) --- incomplete
- Bus Reset
- Set_Address              --- success
- Get_Descriptor( Device ) --- incomplete
- Get_Descriptor( Device ) --- incomplete
- Get_Descriptor( Device ) --- incomplete

All of Get_Descriptor fails on its STATUS stage.
Host puts ZLP (Zero-Length Packet) to the default OUT endpoint, but the device is NAKing until time out.

This means the default OUT endpoint is still occupied by the SETUP packet.
The endpoint buffer is not cleared correctly, after read out on the SETUP handler.

In USB_ReadEP(), you try to send "Select Endpoint" and "Clear Buffer" command to the device protocol engine using wr_cmd_H().
But these commands don't take any data to write on the data phase. Just optional read.
Then, I add new wr_cmd() and modified USB_ReadEP() as follows.

// <------- add a subroutine to write a command to the protocol engine without any data

void wr_cmd( unsigned long send_cmd )
{
    USBDevIntClr=0x10;               //clear cmd_code_empty
    USBCmdCode=send_cmd|usbcmd;      //configure device
    while(!(USBDevIntSt & 0x10));    //wait cmd_code_empty
    USBDevIntClr=0x10;               //clear cmd_code_empty interrupt bit
}

unsigned long USB_ReadEP (unsigned long EPNum, unsigned char *pData)
{
    unsigned long cnt, n, phy_num;

    USBCtrl = 0x00000001|EPNum<<2;

    do  {
        cnt = USBRxPLen;
    }while ((cnt & PKT_RDY) == 0);

    cnt &= PKT_LNGTH_MASK;

    for (n = 0; n < (cnt + 3) / 4; n++)
    {
        *((__packed unsigned long *)pData) = USBRxData;
        pData += 4;
    }

    USBCtrl = 0;
    phy_num = EPAdr(EPNum);

//    wr_cmd_H(phy_num,(phy_num|0x00000200));     // <------ these commands are wrong
//    wr_cmd_H(0xF2,0x00F20200);
                                                  // <------ replaced with right ones
    wr_cmd( 0x00000500 | phy_num );     // select endpoint command
    wr_cmd( 0x00F20500 );               // clear buffer command

    return (cnt);
}

Also, to unload ZLP of the STATUS stage from the default OUT endpoint, this temporary fix was added.

void USB_ISR (void) __irq
{
    ...
    ...
        if (val & 0x04) //STP user manual page number 229
        {
            USBDevIntClr = dev_stat;
            Ep0_setup();
            continue;
        }
//**************** modified from here
        else {
                                                  // temporary fix for status stage
            USB_ReadEP(0x00, EP0Data.pData);      // unload ZLP
        }
//**************** modified to here
    ...
    ...

Now, the trace was improved one step further.

- Bus Reset
- Get_Descriptor( Device ) --- success
- Bus Reset
- Set_Address              --- success
- Get_Descriptor( Device ) --- success
- Get_Descriptor( Config ) --- incomplete

Get_Descriptor( Config ) is disturbed by "while(1);", inserted by you for debug ;-)

Not just USB_ReadEP(). You are using wr_cmd_H() wrongly everywhere on your code.
Check them all.

Tsuneo

Thank you very much!
I made those changes in my code and it worked properly.
You have helped us a lot in our project and we will require your valuable guidance in further development.

We successfully sent our configuration descriptor. Now when our board is connected, it shows mass storage device found. But still does not support that device.
I am getting Set_cofiguration command but what am I supposed to do in its response?
I am executing configure command in protocol engine in its response.
As mine is mass storage device, can you please tell me what events are expected further? What is sequence of next requests from host?

Implementing class requests for mass storage class.
Got GET MAX LUN request.
Replied it with value zero.
using bus hound software. so my device replies with 1 byte that is 0. but host does not respond.
why is this so?

1. I stalled control IN endpoint.
I got clear_feature command then.
I replied to it just by executing
Set_Endpoint_Status (IN EP0: 0x00410500, ST bit: 0x00000100) and sent zero length packet.
When i analyzed Bus hound, host does not respond after clear_feature.
It again asks
1. Get max lun
2. Clear_feature
and does it for 3 times to Reset the device.
What should i do?

2. I am getting string descriptor request for language id and serial no. but not for manufacturer string. I checked for device descriptor index fields. it seems to be fine. What can be the problem?

> 1. I stalled control IN endpoint.
I got clear_feature command then.

Ummm...
Clear_Feature is unexpected response.
For protocol STALL on default endpoint, Clear_Feature is not issued.
Clear_Feature is used for recovery of bulk/interrupt endpoint.

a) Which endpoint does the Clear_Feature points,
Post the 8 byte SETUP data of the Clear_Feature

b) Do you see any other bus activity between Get_Max_LUN and Clear_Feature on bus hound?
Does the host happen to send CBW to bulk OUT endpoint?

Tsuneo