How to opena handle to "Cypress EZ-USB FX2 (68613) - EEPROM missing" and download a program to RAM

"runner" <emb@dded> wrote in message 
news:466fe158$0$37202$4fafbaef@reader3.news.tin.it...
>> > How do you show that?
>> >
>> >
>>
>> By loading all 9K into RAM and then checking.  Had there been wrap 
>> around,
>> the bottom 1K would not verify, though the top 1K would, spuriously.
> That's
>> why I load all 9K in and then verify all 9K.  Simple read-after-write
>> verification provides spurious reassurance.
>>
> What i don't understand is... you said: "I just need to get a file handle
> and then use some library function to send 0xA0 commands to fill
> memory". And then you said that you have troubles in doing so. So i
> ask you "how could you issue an 0xA0 request and see it working?"

Because I have found out how to open a handle (use Code 1 below) and then 
use Code 2 belkow to read/write RAM.

>
> Is 0xA0 request working?
> Is your vend-ax derived code working?

It seems to be.

>
> As i told you i don't remember where i read about the 8K limitation.
> (Perhaps i had a vision). But i remember that John Hyde used the
> "mover code trick" in a loader driver. I didn't base my driver on that so
> i can't tell you more. Note: the driver was for the older version of the
> ez-usb chip, AN21xx.

Eeek.  Another generation!  Well done on surviving.

>
>
>
>

Code 1:
os << "\\\\.\\ezusb-" << InterfaceNumber << ends;

}

hCypress = CreateFile( DeviceFileName,

GENERIC_WRITE,

FILE_SHARE_WRITE,

NULL,

OPEN_EXISTING,

0,

NULL);

if (hCypress == INVALID_HANDLE_VALUE)



Code 2:

VENDOR_OR_CLASS_REQUEST_CONTROL myRequest;

myRequest.request = (BYTE) VR_ANCHOR_LOAD_INTERNAL;

myRequest.value = (WORD) Offset;

myRequest.index = (WORD) 0x00;

myRequest.direction = ReadFlag ? DIR_FROM_DEVICE : DIR_TO_DEVICE;

myRequest.requestType = REQ_VENDOR;

myRequest.recepient = TGT_DEVICE;


const BOOL bResult = DeviceIoControl ( hDevice,

IOCTL_EZUSB_VENDOR_OR_CLASS_REQUEST,

&myRequest,

sizeof(VENDOR_OR_CLASS_REQUEST_CONTROL),

(LPVOID)pData,

nBytesToTransfer,

&nBytesTransferred,

(LPOVERLAPPED)NULL);

if ( bResult == FALSE )

{

> > As i told you i don't remember where i read about the 8K limitation.
> > (Perhaps i had a vision). But i remember that John Hyde used the
> > "mover code trick" in a loader driver. I didn't base my driver on that
so
> > i can't tell you more. Note: the driver was for the older version of the
> > ez-usb chip, AN21xx.
>
> Eeek.  Another generation!  Well done on surviving.
>

Now i recall where i read about the 8K limit. It was not in the manual, it
was at

http://pages.cpsc.ucalgary.ca/~walpole/525/FRIESS%20and%20MCNEIL/code/USB-FPGA/fx2comms/fx2comms.cpp

Read the comment above the function:

FX2COMMS_API int fx2_load_firmware(char *filename)

I found a copy of the general purpose driver specs. The ANCHOR_DOWNLOAD
ioctl says that the download size must be <= 7K. "fx2_load_firmware" uses
that.

The VENDOR_OR_CLASS_REQUEST you're using now doesn't say anything about the
size. Do you write 9K in just one large transfer?

Hi

Well, it does seem to write one very big slab of RAM (in excess of 8K). 
This to to an FX2LP of course.  I limit EzUsb transfers to 1024 and CyUsb 
transfers to 4096.  Not sure why, but it works.  I'd be happy to zip up the 
source code, if anyone is interested; it's simple C++ under Microsoft Visual 
C++ 2003'ish, but it is just a lash up.

Rgds,

   Bill

Opened: \\.\ezusb-0
Writing 1 bytes of RAM at 0xe600
Writing 69 bytes of RAM at 0x0
Writing 15 bytes of RAM at 0x46
Writing 8570 bytes of RAM at 0x56
Reading 69 bytes of RAM at 0x0
Reading 15 bytes of RAM at 0x46
Reading 8570 bytes of RAM at 0x56
RAM verified
Writing 1 bytes of RAM at 0xe600
Waiting 5 seconds to enumerate
Opened: 
\\?\usb#vid_16cb&pid_8f00#serno.0000#{f618a337-2b7a-4115-aeaf-578a16a66677}
Writing 8711 bytes of EEPROM at 0x0
Writing took 0.831 milliseconds
Reading 8711 bytes of EEPROM at 0x0
Reading took 0.351 milliseconds
EEPROM verified



CreatFile(\\.\ezusb-0, ...): The system cannot find the file specified.
Opened: 
\\?\usb#vid_16cb&pid_8f00#serno.0000#{f618a337-2b7a-4115-aeaf-578a16a66677}
Writing 1 bytes of RAM at 0xe600
Writing 69 bytes of RAM at 0x0
Writing 15 bytes of RAM at 0x46
Writing 8570 bytes of RAM at 0x56
Reading 69 bytes of RAM at 0x0
Reading 15 bytes of RAM at 0x46
Reading 8570 bytes of RAM at 0x56
RAM verified
Writing 1 bytes of RAM at 0xe600
Waiting 5 seconds to enumerate
Opened: 
\\?\usb#vid_16cb&pid_8f00#serno.0000#{f618a337-2b7a-4115-aeaf-578a16a66677}
Writing 8711 bytes of EEPROM at 0x0
Writing took 0.832 milliseconds
Reading 8711 bytes of EEPROM at 0x0
Reading took 0.34 milliseconds
EEPROM verified


"runner" <emb@dded> wrote in message 
news:46706ba8$0$37203$4fafbaef@reader3.news.tin.it...
>
>> > As i told you i don't remember where i read about the 8K limitation.
>> > (Perhaps i had a vision). But i remember that John Hyde used the
>> > "mover code trick" in a loader driver. I didn't base my driver on that
> so
>> > i can't tell you more. Note: the driver was for the older version of 
>> > the
>> > ez-usb chip, AN21xx.
>>
>> Eeek.  Another generation!  Well done on surviving.
>>
>
> Now i recall where i read about the 8K limit. It was not in the manual, it
> was at
>
> http://pages.cpsc.ucalgary.ca/~walpole/525/FRIESS%20and%20MCNEIL/code/USB-FPGA/fx2comms/fx2comms.cpp
>
> Read the comment above the function:
>
> FX2COMMS_API int fx2_load_firmware(char *filename)
>
> I found a copy of the general purpose driver specs. The ANCHOR_DOWNLOAD
> ioctl says that the download size must be <= 7K. "fx2_load_firmware" uses
> that.
>
> The VENDOR_OR_CLASS_REQUEST you're using now doesn't say anything about 
> the
> size. Do you write 9K in just one large transfer?
>
>
> 

"Bill Davy" <Bill@SynectixLtd.com> wrote in message
news:-sidnTUqfb6wkOzbRVnyiwA@bt.com...
> Hi
>
> Well, it does seem to write one very big slab of RAM (in excess of 8K).
> This to to an FX2LP of course.  I limit EzUsb transfers to 1024 and CyUsb
> transfers to 4096.  Not sure why, but it works.  I'd be happy to zip up
the
> source code, if anyone is interested; it's simple C++ under Microsoft
Visual
> C++ 2003'ish, but it is just a lash up.
>

Thanks for the code :) but i'm not using Cypress' tools.
I guess that this 8K limit will remain a mystery. I have the impression
that if the start address is at an offset that is lower than 8K the
transfer will succeed even if a big chunk exceeds the address 0x2000.
On the other hand, if you write a chunk that is completely contained
in the range [8k,16k[ it might fail. I don't know for sure. Anyway i don't
have much time to setup a test. I just remember that when i told the
compiler to put "initialized" xdata above 0x2000 the code didn't
find the expected data and behaved incorrectly. When i put the
xdata @ 0x1200 (for example) everything worked fine.
When i say "completely contained" i mean a line like ":LL200000..."
in the ".ihx" file, where LL is the record length.

"runner" <emb@dded> wrote in message 
news:46712139$0$37204$4fafbaef@reader3.news.tin.it...
>
> "Bill Davy" <Bill@SynectixLtd.com> wrote in message
> news:-sidnTUqfb6wkOzbRVnyiwA@bt.com...
>> Hi
>>
>> Well, it does seem to write one very big slab of RAM (in excess of 8K).
>> This to to an FX2LP of course.  I limit EzUsb transfers to 1024 and CyUsb
>> transfers to 4096.  Not sure why, but it works.  I'd be happy to zip up
> the
>> source code, if anyone is interested; it's simple C++ under Microsoft
> Visual
>> C++ 2003'ish, but it is just a lash up.
>>
>
> Thanks for the code :) but i'm not using Cypress' tools.
> I guess that this 8K limit will remain a mystery. I have the impression
> that if the start address is at an offset that is lower than 8K the
> transfer will succeed even if a big chunk exceeds the address 0x2000.
> On the other hand, if you write a chunk that is completely contained
> in the range [8k,16k[ it might fail. I don't know for sure. Anyway i don't
> have much time to setup a test. I just remember that when i told the
> compiler to put "initialized" xdata above 0x2000 the code didn't
> find the expected data and behaved incorrectly. When i put the
> xdata @ 0x1200 (for example) everything worked fine.
> When i say "completely contained" i mean a line like ":LL200000..."
> in the ".ihx" file, where LL is the record length.
>
>
>

Many thanks for that information.

And just to conclude this tale with a last curiosity, the Cypress core seems 
to mishandle 0xA0 In requests (which I use to read back RAM for 
verification) if the offset is odd (it is treated as next even offset 
below).

And now back to real work, the code that has been downloaded.

Bill 

"Bill Davy" <Bill@SynectixLtd.com> wrote in message
news:L8Gdncm3ebOhsuzbRVnytwA@bt.com...
>
> "runner" <emb@dded> wrote in message
> news:46712139$0$37204$4fafbaef@reader3.news.tin.it...
> >
> > "Bill Davy" <Bill@SynectixLtd.com> wrote in message
> > news:-sidnTUqfb6wkOzbRVnyiwA@bt.com...
> >> Hi
> >>
> >> Well, it does seem to write one very big slab of RAM (in excess of 8K).
> >> This to to an FX2LP of course.  I limit EzUsb transfers to 1024 and
CyUsb
> >> transfers to 4096.  Not sure why, but it works.  I'd be happy to zip up
> > the
> >> source code, if anyone is interested; it's simple C++ under Microsoft
> > Visual
> >> C++ 2003'ish, but it is just a lash up.
> >>
> >
> > Thanks for the code :) but i'm not using Cypress' tools.
> > I guess that this 8K limit will remain a mystery. I have the impression
> > that if the start address is at an offset that is lower than 8K the
> > transfer will succeed even if a big chunk exceeds the address 0x2000.
> > On the other hand, if you write a chunk that is completely contained
> > in the range [8k,16k[ it might fail. I don't know for sure. Anyway i
don't
> > have much time to setup a test. I just remember that when i told the
> > compiler to put "initialized" xdata above 0x2000 the code didn't
> > find the expected data and behaved incorrectly. When i put the
> > xdata @ 0x1200 (for example) everything worked fine.
> > When i say "completely contained" i mean a line like ":LL200000..."
> > in the ".ihx" file, where LL is the record length.
> >
> >
> >
>
> Many thanks for that information.
>
> And just to conclude this tale with a last curiosity, the Cypress core
seems
> to mishandle 0xA0 In requests (which I use to read back RAM for
> verification) if the offset is odd (it is treated as next even offset
> below).
>
> And now back to real work, the code that has been downloaded.
>
> Bill

The manual states that the start address must be word aligned.
(chapter 3.8 at the top of page 3-12)

"runner" <emb@dded> wrote in message 
news:46713bda$0$4788$4fafbaef@reader4.news.tin.it...
>
> "Bill Davy" <Bill@SynectixLtd.com> wrote in message
> news:L8Gdncm3ebOhsuzbRVnytwA@bt.com...
>>
>> "runner" <emb@dded> wrote in message
>> news:46712139$0$37204$4fafbaef@reader3.news.tin.it...
>> >
>> > "Bill Davy" <Bill@SynectixLtd.com> wrote in message
>> > news:-sidnTUqfb6wkOzbRVnyiwA@bt.com...
>> >> Hi
>> >>
>> >> Well, it does seem to write one very big slab of RAM (in excess of 
>> >> 8K).
>> >> This to to an FX2LP of course.  I limit EzUsb transfers to 1024 and
> CyUsb
>> >> transfers to 4096.  Not sure why, but it works.  I'd be happy to zip 
>> >> up
>> > the
>> >> source code, if anyone is interested; it's simple C++ under Microsoft
>> > Visual
>> >> C++ 2003'ish, but it is just a lash up.
>> >>
>> >
>> > Thanks for the code :) but i'm not using Cypress' tools.
>> > I guess that this 8K limit will remain a mystery. I have the impression
>> > that if the start address is at an offset that is lower than 8K the
>> > transfer will succeed even if a big chunk exceeds the address 0x2000.
>> > On the other hand, if you write a chunk that is completely contained
>> > in the range [8k,16k[ it might fail. I don't know for sure. Anyway i
> don't
>> > have much time to setup a test. I just remember that when i told the
>> > compiler to put "initialized" xdata above 0x2000 the code didn't
>> > find the expected data and behaved incorrectly. When i put the
>> > xdata @ 0x1200 (for example) everything worked fine.
>> > When i say "completely contained" i mean a line like ":LL200000..."
>> > in the ".ihx" file, where LL is the record length.
>> >
>> >
>> >
>>
>> Many thanks for that information.
>>
>> And just to conclude this tale with a last curiosity, the Cypress core
> seems
>> to mishandle 0xA0 In requests (which I use to read back RAM for
>> verification) if the offset is odd (it is treated as next even offset
>> below).
>>
>> And now back to real work, the code that has been downloaded.
>>
>> Bill
>
> The manual states that the start address must be word aligned.
> (chapter 3.8 at the top of page 3-12)
>
>

Interesting.  My printed copy (v2.1) does not have such a comment anywhere 
is Section 3.8 (though it is on pps 3-11 and 3-12) but it does apply to the 
FX2 (just tried it).  I just checked EZ USB_TRM.pdf (Last Updated 21 Mar, 
2007) on the Cypress web site and it does indeed note that the address must 
be word aligned for Upload.  Better get myself a copy.

Bill

PS Why do so many examples use EA to freeze/release interrupts when 
accessing shared data?  I use ES0 for the serial port, ET0 for timer 0, and 
reserve EA for the global enable at start up.  But then I may have a problem 
with interrupts.

> PS Why do so many examples use EA to freeze/release interrupts when
> accessing shared data?  I use ES0 for the serial port, ET0 for timer 0,
and
> reserve EA for the global enable at start up.  But then I may have a
problem
> with interrupts.
>

Which examples?

"runner" <emb@dded> wrote in message 
news:46716af9$0$4789$4fafbaef@reader4.news.tin.it...
>> PS Why do so many examples use EA to freeze/release interrupts when
>> accessing shared data?  I use ES0 for the serial port, ET0 for timer 0,
> and
>> reserve EA for the global enable at start up.  But then I may have a
> problem
>> with interrupts.
>>
>
> Which examples?
>
>

Cannot find one now (of course), but when next I do ...