Cypress EZ-USB downloader

bridged with qdn.public.ddk.usb
Post Reply
Phil Olynyk

Cypress EZ-USB downloader

Post by Phil Olynyk » Fri Feb 01, 2002 4:36 pm

Hi -
I am trying to get a download program working for the Cypress EZ-USB
chip. Since it only has ram, you have to download code into it before it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Markus Lavin

Re: Cypress EZ-USB downloader

Post by Markus Lavin » Fri Feb 08, 2002 12:05 pm

Hi Phil!

If you havn't succeded alreay, I might be able to help. I've used a similar
chip and successfully load intel hex code into it from a QNX box.

The follwoing code should work, (I havn't tested).

//assuming "dev" is the qnx usb handle for the ezusb device.

struct usbd_urb* urb;
struct usbd_pipe* pipe;
usbd_endpoint_descriptor_t *ep_desc;
struct usbd_desc_node *node;

char *usbbuf = (char*)usbd_alloc(1024);

ep_desc = usbd_endpoint_descriptor(dev, 1, 0, 0, 0, &node);
usbd_open_pipe(dev, ep_desc, &pipe);
urb = usbd_alloc_urb(NULL);

usbbuf[0] = 0x01; /* reset bit */

//first place the CPU in reset allowing code download
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

for (every line in the intel hex file) {
/* parse the address and the byte sequence and place them in 'address' and
'usbbuf', 'length' shall be the length of the usbbuf. */

usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
address, // address
0x0000, // Index, not used
usbbuf, // the content
length); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?
}

//bring the cpu out of reset
usbbuf[0] = 0x00; /* no reset bit */
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

The 8051 CPU should now start executing whatever code that was loaded into
it.

Hope this helps! And if it doesn't, you could always post your code..

regards
/Markus





"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C5AC404.A4950E7D@home.com...
Hi -
I am trying to get a download program working for the Cypress EZ-USB
chip. Since it only has ram, you have to download code into it before it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Phil Olynyk

Re: Cypress EZ-USB downloader

Post by Phil Olynyk » Mon Feb 11, 2002 5:18 pm

Thanks Markus -
I thought I did have pretty close to what you suggested, but just to make
sure I put in your changes - mainly the use of the particular interface, rather
than letting ezusb-parse-descriptors find it. Still no go. The LED's come on
solid, and there is no re-enumeration. Since I can't seem to get into my
rogers.com site, I have attached my c and h files.
I am open to any suggestions.

Phil Olynyk

Markus Lavin wrote:
Hi Phil!

If you havn't succeded alreay, I might be able to help. I've used a similar
chip and successfully load intel hex code into it from a QNX box.

The follwoing code should work, (I havn't tested).

//assuming "dev" is the qnx usb handle for the ezusb device.

struct usbd_urb* urb;
struct usbd_pipe* pipe;
usbd_endpoint_descriptor_t *ep_desc;
struct usbd_desc_node *node;

char *usbbuf = (char*)usbd_alloc(1024);

ep_desc = usbd_endpoint_descriptor(dev, 1, 0, 0, 0, &node);
usbd_open_pipe(dev, ep_desc, &pipe);
urb = usbd_alloc_urb(NULL);

usbbuf[0] = 0x01; /* reset bit */

//first place the CPU in reset allowing code download
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

for (every line in the intel hex file) {
/* parse the address and the byte sequence and place them in 'address' and
'usbbuf', 'length' shall be the length of the usbbuf. */

usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
address, // address
0x0000, // Index, not used
usbbuf, // the content
length); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?
}

//bring the cpu out of reset
usbbuf[0] = 0x00; /* no reset bit */
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to device
0xA0, // Request=Firmware load
USB_TYPE_VENDOR, // Request type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

The 8051 CPU should now start executing whatever code that was loaded into
it.

Hope this helps! And if it doesn't, you could always post your code..

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C5AC404.A4950E7D@home.com...
Hi -
I am trying to get a download program working for the Cypress EZ-USB
chip. Since it only has ram, you have to download code into it before it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Markus Lavin

Re: Cypress EZ-USB downloader

Post by Markus Lavin » Tue Feb 12, 2002 11:20 am

I've had a quick look at your source, and it seems ok I quess. Anyways, you
said in a eariler mail that the code downloaded without any problems and you
then you uploaded it and compared it, which turned out to match?

If the code matches and the CPU_CS register is written correctly, then what
seems most likely to me (im just guessing) is that the intel hex convertion
routines mess up somehow and the 8051 cant execute the faulty code, thus it
can not reenumerat on the bus (as the reenumeration is the responisibility
of the newly downloaded code).

regards
/Markus


"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C67FCF4.6C32A5FB@home.com...
Thanks Markus -
I thought I did have pretty close to what you suggested, but just to
make
sure I put in your changes - mainly the use of the particular interface,
rather
than letting ezusb-parse-descriptors find it. Still no go. The LED's come
on
solid, and there is no re-enumeration. Since I can't seem to get into my
rogers.com site, I have attached my c and h files.
I am open to any suggestions.

Phil Olynyk

Markus Lavin wrote:

Hi Phil!

If you havn't succeded alreay, I might be able to help. I've used a
similar
chip and successfully load intel hex code into it from a QNX box.

The follwoing code should work, (I havn't tested).

//assuming "dev" is the qnx usb handle for the ezusb device.

struct usbd_urb* urb;
struct usbd_pipe* pipe;
usbd_endpoint_descriptor_t *ep_desc;
struct usbd_desc_node *node;

char *usbbuf = (char*)usbd_alloc(1024);

ep_desc = usbd_endpoint_descriptor(dev, 1, 0, 0, 0, &node);
usbd_open_pipe(dev, ep_desc, &pipe);
urb = usbd_alloc_urb(NULL);

usbbuf[0] = 0x01; /* reset bit */

//first place the CPU in reset allowing code download
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

for (every line in the intel hex file) {
/* parse the address and the byte sequence and place them in 'address'
and
'usbbuf', 'length' shall be the length of the usbbuf. */

usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
address, // address
0x0000, // Index, not used
usbbuf, // the content
length); // Length of
buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?
}

//bring the cpu out of reset
usbbuf[0] = 0x00; /* no reset bit */
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

The 8051 CPU should now start executing whatever code that was loaded
into
it.

Hope this helps! And if it doesn't, you could always post your code..

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C5AC404.A4950E7D@home.com...
Hi -
I am trying to get a download program working for the Cypress
EZ-USB
chip. Since it only has ram, you have to download code into it before
it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a
confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which
is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Phil Olynyk

Re: Cypress EZ-USB downloader-- WEIRD!

Post by Phil Olynyk » Thu Feb 14, 2002 3:22 pm

Hi Marcus -
As a result of a suggestion from Mario Charest, I tried again, but happened
to have made a couple of changes...
On a different machine, I used the devu-ohci stack and _no_ intermediate hub
(it's still on the other -devu-uhci- machine).
And this time it worked fine, the power light is now cycling nicely...

So some further experiments are in order, to pin down the problem to the stack,
or that hub, or any hub? We shall see - after i get other work out of the way!

Thanks - Phil Olynyk

Markus Lavin wrote:
I've had a quick look at your source, and it seems ok I quess. Anyways, you
said in a eariler mail that the code downloaded without any problems and you
then you uploaded it and compared it, which turned out to match?

If the code matches and the CPU_CS register is written correctly, then what
seems most likely to me (im just guessing) is that the intel hex convertion
routines mess up somehow and the 8051 cant execute the faulty code, thus it
can not reenumerat on the bus (as the reenumeration is the responisibility
of the newly downloaded code).

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C67FCF4.6C32A5FB@home.com...
Thanks Markus -
I thought I did have pretty close to what you suggested, but just to
make
sure I put in your changes - mainly the use of the particular interface,
rather
than letting ezusb-parse-descriptors find it. Still no go. The LED's come
on
solid, and there is no re-enumeration. Since I can't seem to get into my
rogers.com site, I have attached my c and h files.
I am open to any suggestions.

Phil Olynyk

Markus Lavin wrote:

Hi Phil!

If you havn't succeded alreay, I might be able to help. I've used a
similar
chip and successfully load intel hex code into it from a QNX box.

The follwoing code should work, (I havn't tested).

//assuming "dev" is the qnx usb handle for the ezusb device.

struct usbd_urb* urb;
struct usbd_pipe* pipe;
usbd_endpoint_descriptor_t *ep_desc;
struct usbd_desc_node *node;

char *usbbuf = (char*)usbd_alloc(1024);

ep_desc = usbd_endpoint_descriptor(dev, 1, 0, 0, 0, &node);
usbd_open_pipe(dev, ep_desc, &pipe);
urb = usbd_alloc_urb(NULL);

usbbuf[0] = 0x01; /* reset bit */

//first place the CPU in reset allowing code download
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

for (every line in the intel hex file) {
/* parse the address and the byte sequence and place them in 'address'
and
'usbbuf', 'length' shall be the length of the usbbuf. */

usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
address, // address
0x0000, // Index, not used
usbbuf, // the content
length); // Length of
buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?
}

//bring the cpu out of reset
usbbuf[0] = 0x00; /* no reset bit */
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

The 8051 CPU should now start executing whatever code that was loaded
into
it.

Hope this helps! And if it doesn't, you could always post your code..

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C5AC404.A4950E7D@home.com...
Hi -
I am trying to get a download program working for the Cypress
EZ-USB
chip. Since it only has ram, you have to download code into it before
it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a
confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which
is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Phil Olynyk

Re: Cypress EZ-USB downloader-- TI hub fails re-enumeration

Post by Phil Olynyk » Fri Feb 15, 2002 3:52 am

I've tried my downloader on both stacks now, and it works just fine if I connect
directly to the root hub. If I use either of my hubs (both have the same TI chip -
vendor 0451, product 1446 ), the re-enumeration fails. I don't know if this is a
bug in the hub chip or in the enumeration code in the USB stack. Mario mentioned to
me that he had troubles when there was a hub in the path, but I don't know what
chip his hub was using. One of my hubs is a Linksys 4 port, the other is a NoName 4
port.
So that's it for now. I'll do direct connect while I work on my USBmidi
driver...

Phil Olynyk
OBT Software Corp.


Phil Olynyk wrote:
Hi Marcus -
As a result of a suggestion from Mario Charest, I tried again, but happened
to have made a couple of changes...
On a different machine, I used the devu-ohci stack and _no_ intermediate hub
(it's still on the other -devu-uhci- machine).
And this time it worked fine, the power light is now cycling nicely...

So some further experiments are in order, to pin down the problem to the stack,
or that hub, or any hub? We shall see - after i get other work out of the way!

Thanks - Phil Olynyk

Markus Lavin wrote:

I've had a quick look at your source, and it seems ok I quess. Anyways, you
said in a eariler mail that the code downloaded without any problems and you
then you uploaded it and compared it, which turned out to match?

If the code matches and the CPU_CS register is written correctly, then what
seems most likely to me (im just guessing) is that the intel hex convertion
routines mess up somehow and the 8051 cant execute the faulty code, thus it
can not reenumerat on the bus (as the reenumeration is the responisibility
of the newly downloaded code).

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C67FCF4.6C32A5FB@home.com...
Thanks Markus -
I thought I did have pretty close to what you suggested, but just to
make
sure I put in your changes - mainly the use of the particular interface,
rather
than letting ezusb-parse-descriptors find it. Still no go. The LED's come
on
solid, and there is no re-enumeration. Since I can't seem to get into my
rogers.com site, I have attached my c and h files.
I am open to any suggestions.

Phil Olynyk

Markus Lavin wrote:

Hi Phil!

If you havn't succeded alreay, I might be able to help. I've used a
similar
chip and successfully load intel hex code into it from a QNX box.

The follwoing code should work, (I havn't tested).

//assuming "dev" is the qnx usb handle for the ezusb device.

struct usbd_urb* urb;
struct usbd_pipe* pipe;
usbd_endpoint_descriptor_t *ep_desc;
struct usbd_desc_node *node;

char *usbbuf = (char*)usbd_alloc(1024);

ep_desc = usbd_endpoint_descriptor(dev, 1, 0, 0, 0, &node);
usbd_open_pipe(dev, ep_desc, &pipe);
urb = usbd_alloc_urb(NULL);

usbbuf[0] = 0x01; /* reset bit */

//first place the CPU in reset allowing code download
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

for (every line in the intel hex file) {
/* parse the address and the byte sequence and place them in 'address'
and
'usbbuf', 'length' shall be the length of the usbbuf. */

usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
address, // address
0x0000, // Index, not used
usbbuf, // the content
length); // Length of
buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?
}

//bring the cpu out of reset
usbbuf[0] = 0x00; /* no reset bit */
usbIoRes = usbd_setup_vendor(urb, // URB used
URB_DIR_OUT, // Flags=PC to
device
0xA0, // Request=Firmware
load
USB_TYPE_VENDOR, // Request
type,rtype=40
0x7f92, // address
0x0000, // Index, not used
usbbuf, // the content
1); // Length of buffer

usbIoRes = usbd_io(urb, // URB used
pipe, // Pipe used
NULL, // (Call back function)
NULL, // (Message to callback)
USBD_TIME_INFINITY); // Must work?

The 8051 CPU should now start executing whatever code that was loaded
into
it.

Hope this helps! And if it doesn't, you could always post your code..

regards
/Markus

"Phil Olynyk" <pholynyk@home.com> wrote in message
news:3C5AC404.A4950E7D@home.com...
Hi -
I am trying to get a download program working for the Cypress
EZ-USB
chip. Since it only has ram, you have to download code into it before
it
becomes at all useful. Here is the manufacture's web site:
http://www.cypress.com/usb/fullspeed/ezusb.html
I found some Linux code at
http://ezusb2131.sourceforge.net
This code works for Linux. Not exactly a surprise, but a
confidence
builder. I have tried to convert this code, and it seems to download
something, and it compares nicely if I upload it; BUT the chip
disconnects and just hangs without allowing the re-enumeration which
is
supposed to happen. The usb utility can't see anything new on the bus.
You can see my previous post for the main loop chunks, or I could
post my code on my web site if some one want to see the whole thing.
Is there a way to use sloginfo to see what's going out and coming
back on the bus? That would be nice..
Any hints or ideas would be appreciated..

Thanks, Phil Olynyk
OBT Software Corp.

Post Reply

Return to “qdn.public.ddk.usb”