Prev: Atmel AT89c51ed2 isp bootloader - no longer able to sync
Next: About NXP TDA8007 (smart-card chip controller)
From: runner on 12 Jun 2007 10:52

"Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
news:_IidnQhcvPQ36PPbnZ2dnUVZ8taknZ2d(a)bt.com...
>
> "runner" <emb(a)dded> wrote in message
> news:46699ea3$0$17946$4fafbaef(a)reader1.news.tin.it...
> >> EZ-USB seems to be truncating the program at 8K when the FX2LP goes to
16
> > K.
> >>
> >> However, Marc's uggestion I look at EZMR may help (the wrapping is
there
> >> too, but accessible). I too am now writng a command line (console)
> >> application to bring a chip up from the "No EEPROM" state.
> >>
> >
> > There is no way you can upload the higher 8K by an
> > "A0 Request". It is written somewhere in the manual.
> > Don't ask me where. The last time i checked i had a
> > hard time. The solution is to upload a small relocator
> > first. It loads the higher 8K by relocating. Then you
> > upload the lower 8K.
> >
> >
> >
>
> The FX2LP core seems to load the 16K fine using A0 command. At least, I
> load 8K+ bytes and then verify they are as written.

How do you show that?


From: Bill Davy on 13 Jun 2007 06:46

"runner" <emb(a)dded> wrote in message
news:466eb097$0$37205$4fafbaef(a)reader3.news.tin.it...
>
> "Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
> news:_IidnQhcvPQ36PPbnZ2dnUVZ8taknZ2d(a)bt.com...
>>
>> "runner" <emb(a)dded> wrote in message
>> news:46699ea3$0$17946$4fafbaef(a)reader1.news.tin.it...
>> >> EZ-USB seems to be truncating the program at 8K when the FX2LP goes to
> 16
>> > K.
>> >>
>> >> However, Marc's uggestion I look at EZMR may help (the wrapping is
> there
>> >> too, but accessible). I too am now writng a command line (console)
>> >> application to bring a chip up from the "No EEPROM" state.
>> >>
>> >
>> > There is no way you can upload the higher 8K by an
>> > "A0 Request". It is written somewhere in the manual.
>> > Don't ask me where. The last time i checked i had a
>> > hard time. The solution is to upload a small relocator
>> > first. It loads the higher 8K by relocating. Then you
>> > upload the lower 8K.
>> >
>> >
>> >
>>
>> The FX2LP core seems to load the 16K fine using A0 command. At least, I
>> load 8K+ bytes and then verify they are as written.
>
> 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.


From: runner on 13 Jun 2007 08:32
> > 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?"

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

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.




From: Bill Davy on 13 Jun 2007 12:16

"runner" <emb(a)dded> wrote in message
news:466fe158$0$37202$4fafbaef(a)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 )

{



From: runner on 13 Jun 2007 18:23

> > 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?



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Atmel AT89c51ed2 isp bootloader - no longer able to sync
Next: About NXP TDA8007 (smart-card chip controller)