Any idea why flash programming would fail on the old starter kit (S3,
not S3E)? I cant even load the Digilent demo bitfile without getting a
verification error. The jumper is on default and the board works just
fine otherwise. Flash blanking and readback works just fine.
Anyone out there with a simple ISE project that generates
bitstream/prom and programs the board without using the UI?
[the ironic thing is that the project I am trying to get to work is a
programmer for Atmel flash]
Well, I really had enough of this last night (with Impact crashing
every 5 minutes instead of the usual every 20 minutes). Was so -><-
close to trash the board and pretend it was bricked
Somehow, I forced myself to go back to it when I got home right after
work, and tried to read from flash after configuration. I got
mismatches like this in few places (above: read, below: original mcs):
The error rate is something like 2-3%. The board is new*, the cable is
new. Hell, even the computer I ran this from is shiny new. Everything
works just fine when programming the FPGA directly.
Does Anyone know what the problem is? Is xilinx flash this unreliable,
or am I doing something wrong?
regards
- Burns
* actually its really old, but totally unused. I just haven't cared
enough to play with my xilinx boards. Very much thanks to a scary first
encounter with ISE...
> Well, I really had enough of this last night (with Impact crashing
> every 5 minutes instead of the usual every 20 minutes). Was so -><-
> close to trash the board and pretend it was bricked
>
>
> Somehow, I forced myself to go back to it when I got home right after
> work, and tried to read from flash after configuration. I got
> mismatches like this in few places (above: read, below: original mcs):
>
>
> 7485,7490c7485,7490
> < :10D3A000000000000000000000000000FFFFFFFF81
> < :10D3B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
> < :10D3C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6D
> < :10D3D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
> < :10D3E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D
> < :10D3F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
> ---
>
>>:10D3A000000000000000000000000000000000007D
>>:10D3B000000000000000000000000000000000006D
>>:10D3C000000000000000000000000000000000005D
>>:10D3D000000000000000000000000000000000004D
>>:10D3E000000000000000000000000000000000003D
>>:10D3F000000000000000000000000000000000002D
>
>
>
> The error rate is something like 2-3%. The board is new*, the cable is
> new. Hell, even the computer I ran this from is shiny new. Everything
> works just fine when programming the FPGA directly.
>
> Does Anyone know what the problem is? Is xilinx flash this unreliable,
> or am I doing something wrong?
>
>
> regards
> - Burns
>
>
>
> * actually its really old, but totally unused. I just haven't cared
> enough to play with my xilinx boards. Very much thanks to a scary first
> encounter with ISE...
That looks like it just stopped writing 0's ?
If you read 30 times, do you get the matching 30 results ? - that checks
read integrity.
Can you get the Flash into a device programmer, that can read it.
That gives a second verify of contents.
Are these errors always at start/finish. ?
I have seen other devices flash-error on preamble or post-amble
timing errors.
Hmm, If this is the small S3 starter board that you program via USB?? Err, I
got it from memec for about 100$ a while ago, I don't remember the exact
name (alas it resides in a cupboard somewhere now), anyways in my case the
combined flash-processor-usb packed up after about a week using it, the
documentation was useless, and it looked like a real beast to debug. I had
the same sort of problem meaning I coundn't get a bitstream into the flash
without it becoming corrupt, then of course the S3 programming wouldn't
verify. It would work by JTAG, directly into the FPGA, but that was it.
I'll have a look see if I can find the board - itmight be a batch fault...
Ben
"Jim Granville" <[email protected]> wrote in message
news:44e4dd6b$[email protected]..
> [email protected] wrote:
>
>> Well, I really had enough of this last night (with Impact crashing
>> every 5 minutes instead of the usual every 20 minutes). Was so -><-
>> close to trash the board and pretend it was bricked
>>
>>
>> Somehow, I forced myself to go back to it when I got home right after
>> work, and tried to read from flash after configuration. I got
>> mismatches like this in few places (above: read, below: original mcs):
>>
>>
>> 7485,7490c7485,7490
>> < :10D3A000000000000000000000000000FFFFFFFF81
>> < :10D3B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
>> < :10D3C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6D
>> < :10D3D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
>> < :10D3E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D
>> < :10D3F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
>> ---
>>
>>>:10D3A000000000000000000000000000000000007D
>>>:10D3B000000000000000000000000000000000006D
>>>:10D3C000000000000000000000000000000000005D
>>>:10D3D000000000000000000000000000000000004D
>>>:10D3E000000000000000000000000000000000003D
>>>:10D3F000000000000000000000000000000000002D
>>
>>
>>
>> The error rate is something like 2-3%. The board is new*, the cable is
>> new. Hell, even the computer I ran this from is shiny new. Everything
>> works just fine when programming the FPGA directly.
>>
>> Does Anyone know what the problem is? Is xilinx flash this unreliable,
>> or am I doing something wrong?
>>
>>
>> regards
>> - Burns
>>
>>
>>
>> * actually its really old, but totally unused. I just haven't cared
>> enough to play with my xilinx boards. Very much thanks to a scary first
>> encounter with ISE...
>
> That looks like it just stopped writing 0's ?
>
> If you read 30 times, do you get the matching 30 results ? - that checks
> read integrity.
> Can you get the Flash into a device programmer, that can read it.
> That gives a second verify of contents.
>
> Are these errors always at start/finish. ?
> I have seen other devices flash-error on preamble or post-amble
> timing errors.
>
> -jg
>
>
> Hmm, If this is the small S3 starter board that you program via USB?? Err, I
> got it from memec for about 100$ a while ago, I don't remember the exact
> name (alas it resides in a cupboard somewhere now), anyways in my case the
> combined flash-processor-usb packed up after about a week using it, the
> documentation was useless, and it looked like a real beast to debug. I had
> the same sort of problem meaning I coundn't get a bitstream into the flash
> without it becoming corrupt, then of course the S3 programming wouldn't
> verify. It would work by JTAG, directly into the FPGA, but that was it.
> I'll have a look see if I can find the board - itmight be a batch fault...
sounds fairly similar to the OP's - here is one idea : do Xilinx publish
any FLASH cycle limit guarantees, on these ? - could just be a small
number....
[ The OP could just live with a 2-3% failure.... ]
If those are what's on the PCB under discussion, thanks.
That sounds like a few design iterations !
I guess one way to determine if this is some early failure mode in
FLASH ( or some marginal SW/timing issue) is to change the FLASH.
The OP could try that ?
<paste> [email protected] wrote:
> The error rate is something like 2-3%.
Does this mean it fully pases 97-98% of the time
( fails only one in 30 downloads ), or that the memory compare,
shows a cell-match failure of 2-3%, and a download never fully works ?
Jim Granville wrote:
> Austin Lesea wrote:
>
> > ...
> > http://direct.xilinx.com/bvdocs/publications/ds123.pdf
> > claims 20,00 program/erase cycles.
> > ...
>...
> If those are what's on the PCB under discussion, thanks.
> That sounds like a few design iterations !
>...
Jim,
I think Austin lost a "zero"
the ds123 claims:
"Endurance of 20,000 Program/Erase Cycles"
(20 thousands)