Prev: Atmel AT89c51ed2 isp bootloader - no longer able to sync
Next: About NXP TDA8007 (smart-card chip controller)
From: Bill Davy on 14 Jun 2007 05:41
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(a)dded> wrote in message
news:46706ba8$0$37203$4fafbaef(a)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?
>
>
>


From: runner on 14 Jun 2007 07:17

"Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
news:-sidnTUqfb6wkOzbRVnyiwA(a)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.



From: Bill Davy on 14 Jun 2007 08:07

"runner" <emb(a)dded> wrote in message
news:46712139$0$37204$4fafbaef(a)reader3.news.tin.it...
>
> "Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
> news:-sidnTUqfb6wkOzbRVnyiwA(a)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


From: runner on 14 Jun 2007 09:11

"Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
news:L8Gdncm3ebOhsuzbRVnytwA(a)bt.com...
>
> "runner" <emb(a)dded> wrote in message
> news:46712139$0$37204$4fafbaef(a)reader3.news.tin.it...
> >
> > "Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
> > news:-sidnTUqfb6wkOzbRVnyiwA(a)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)


From: Bill Davy on 14 Jun 2007 10:21

"runner" <emb(a)dded> wrote in message
news:46713bda$0$4788$4fafbaef(a)reader4.news.tin.it...
>
> "Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
> news:L8Gdncm3ebOhsuzbRVnytwA(a)bt.com...
>>
>> "runner" <emb(a)dded> wrote in message
>> news:46712139$0$37204$4fafbaef(a)reader3.news.tin.it...
>> >
>> > "Bill Davy" <Bill(a)SynectixLtd.com> wrote in message
>> > news:-sidnTUqfb6wkOzbRVnyiwA(a)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.


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)