hi, i pluged a jtag adapter to a dwl 7000 xscale based accesspoint=20
the jtag interface is working fine, i get output for detect and detectflash=
, but
the board has a amd 29lv320db printed, only 29lv160 and some others
are supported.
now a can not write to the flash. i tried to upload redboot into the
flash, now the old stuff on this flash is gone (vxworks bootloader).
what can i do right now?
how can i add support for the 29lv320db?
thanks ulf kypke

Hi!
Guennadi's SVF-file triggered a bug in function svf_goto_state(). I have
uploaded a patch that addresses this problem and have received positive
report that programming the XC18V02-VQ44 works now.
Best regards
Arnim

gl@... wrote:
Hi! Hellow! It was a hollyday yesterday, so ive not worked. Now i see if
i can reply all.
> On Mon, 15 Aug 2005, Arnim Laeuger wrote:
>
>> You could try to configure the FPGA for debug purpose. This would
>> exclude timing problems as configuring its SRAM should not be
>> critical in terms of timing.
>
>
> That worked! But, unfortunately, I really need to program the PROM.
> Shall I try to do it slower?
>
When working with xilinx proms i found that there are two version of
them, they have different idcode (1 bit) and the difference is something
about the erasing speed.
One of them, when you send the erase command, dosnt need too much time
to erase and work, the other needs the time or else it throws the errors
as you say.
When working with impact to generate the SVF file, you can check the box
of verify and the lines needed to do so are added to the svf file.
Ive made a little program which reads a bit file and geneartes the SVF
file for a device using a template, made from svf files made with
impact. Using this and a script, i actually do $jbit project.bit XC18V01
and it calls bit2svf and jtag to program the device.
I dont like graphical interfaces. In our lab we use all the xilinx tools
from Makefiles and it is faster.
Now, i have 2 templates for the proms, in both of them i divided by 1000
the delays, except the erasing time of one of them, for the slow one.
Hope it helps.
Saludos, Juan Pablo.
--
Juan Pablo Daniel Borgna -- Técnico Electrónico
INTI-Electrónica e Informática
Dirección: Avenida General Paz 5445 entre Albarellos y Constituyentes
CC157 (CP B1650KNA) San Martín, Bs. As., Argentina TE:+(5411)4724-6200

On Mon, 15 Aug 2005, Arnim Laeuger wrote:
> You could try to configure the FPGA for debug purpose. This would exclude
> timing problems as configuring its SRAM should not be critical in terms of
> timing.
That worked! But, unfortunately, I really need to program the PROM. Shall
I try to do it slower?
In another message you suggested to test a verbose error reporting patch
to svf. Its error messages look like:
Error svf: mismatch at position 4095 for TDO
in input file between line -1073738985 col 1 and line -1073738952 col 114
Error svf: mismatch at position 8189 for TDO
in input file between line -1073738942 col 1 and line -1073738909 col 114
...
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Hi,
> Ok, commented out, it gets through, but then I get lots of
>
> Error svf: mismatch for TDO
> ...
>
> And a second question - if / when I
> manage to flash anything, is there a way to verify the correctness,
> apart from checking the TDO during the flashing?
No idea whether iMPACT offers to generate SVF solely with compare/verify
operations or not. Technically, this might be possible.
> Can it be, that my PC
> is not fast enough to record TDO or is it synchronous with driving the
> TDI?
I don't expect that because TDO is sampled before the next clock on TCK
shifts the chain again.
> I have not disabled FREQUENCY in svf, and it is implemented in my
> jtag with a busy loop.
You could try to configure the FPGA for debug purpose. This would
exclude timing problems as configuring its SRAM should not be critical
in terms of timing.
Cheers
Arnim

>> Error svf: mismatch for TDO
>
>
> A small addition: it first runs for some time (10s of seconds)
> without errors. Does it mean that it manages a few first blocks and
> the verification works too?
Probably yes. There was a patch for the SVF player recently that adds
better diagnostics. Haven't tried it yet but it might tell you where the
error happens and which commands passed up to then.
Best regards
Arnim

On Mon, 15 Aug 2005, gl@... wrote:
> On Mon, 15 Aug 2005, gl@... wrote:
>
>> Ok, commented out, it gets through, but then I get lots of
>>
>> Error svf: mismatch for TDO
>
> A small addition: it first runs for some time (10s of seconds) without
> errors. Does it mean that it manages a few first blocks and the verification
> works too?
Just counted error messages: exactly as many as "long" blocks with TDO.
And the output (expected TDO, mask, read TDO) is every time the same...
Was that SIR command indeed required?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

On Mon, 15 Aug 2005, gl@... wrote:
> Ok, commented out, it gets through, but then I get lots of
>
> Error svf: mismatch for TDO
A small addition: it first runs for some time (10s of seconds) without
errors. Does it mean that it manages a few first blocks and the
verification works too?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Hi Arnim
and thanks for the reply!
On Mon, 15 Aug 2005, Arnim Laeuger wrote:
> The simple solution is to comment the SIR command in question. So far, I have
> not seen cases where the command is absolutely required. Nevertheless, it's
> best to investigate the case before changing something that is not
> understood.
Ok, commented out, it gets through, but then I get lots of
Error svf: mismatch for TDO
...
What can be the reason for those? And a second question - if / when I
manage to flash anything, is there a way to verify the correctness, apart
from checking the TDO during the flashing? Can it be, that my PC is not
fast enough to record TDO or is it synchronous with driving the TDI? I
have not disabled FREQUENCY in svf, and it is implemented in my jtag with
a busy loop.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Hi Guennadi!
> jtag> part 0
> jtag> print
> No. Manufacturer Part Stepping Instruction
> Register
> ---------------------------------------------------------------------------------------------
>
> 0 Xilinx XC3S1000-FG320 0 BYPASS BR
> jtag> instruction BYPASS
> jtag> part 1
> jtag> print
> No. Manufacturer Part Stepping Instruction
> Register
> ---------------------------------------------------------------------------------------------
>
> 1 Xilinx XC18V02-VQ44 0 BYPASS BR
> jtag> svf /mnt/smb/t/gl/von_ah/pci-test.svf
> Warning svf: checking of TDO not supported for SIR.
> This message is only displayed once.
> Error svf: SIR command length inconsistent.
> Error occured for SVF command SIR.
Later versions of iMPACT generate a SIR command with more bits than the
IR actually has. There were several posts to the mailing list concerning
this topic.
http://sourceforge.net/mailarchive/message.php?msg_id=11354510
describes why variable length SIRs are not supported by the current SVF
patch.
http://sourceforge.net/mailarchive/message.php?msg_id=11354509
discusses an occurrence of this problem in detail.
The simple solution is to comment the SIR command in question. So far, I
have not seen cases where the command is absolutely required.
Nevertheless, it's best to investigate the case before changing
something that is not understood.
I do not plan to apply substantial changes to the SVF player until it is
integrated in the jtag tools. That's mainly because I'd like to have a
settled status before progressing with further modifications.
> we only had one part
> (PROM) in the project, do you have to create the SVF file for the entire
> configuration, not just for your target part?
SVF files need to be generated for just your target part. Jtag tools
will handle (i.e. bypass) the other parts in the chain. The file won't
work if it was generated for the entire configuration.
This might not be very intiutive at first glance, but it has the
advantage that an SVF file for a single device is valid for any possible
JTAG chain and is not specific to a certain configuration.
In the meantime, I could test the SVF patch with a chain containing two
parts (EP1C12 and EPM3064) - it worked as described in README.svf.
Best regards
Arnim

On Tue, 26 Apr 2005, JPD Borgna wrote:
> Hi all!
>
> Ive noticed that if I set the frequency, it fails and the proccess end up
> working with a clock of 25 Hz. So i first replaced the usleep with a
> nanosleep and everything it need and NO.
> So, if any of you had this problem, what did you do?
> If not, im thinking in rewriting the delay part, so please say something so i
> dont doit :)
I replaced sleeps with busy-loops to solve this...
Regards
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Hello from Gregg C Levine
When I composed that message earlier this evening, I thought I remembered
seeing something of a sort stating that, in conjunction with the JTAG page,
or pages on the site. After it went to the list, I suddenly remembered that
it was not with the pages that were imported from the iPaq site, nor the
ones for the JTAG pages, but probably someplace else. And no I can't
remember where. It's just not recommended is what I do recall. Of course I
could be wrong.
What is strange is that your arrangement that I first saw with regards to
the iPaq, was the adopted one by a group that's also doing stuff to the
wireless routers from LinkSys.
---
Gregg C Levine yodathejediknight@...
----- Original Message -----
From: "Marcel Telka" <marcel@...>
To: <openwince-list@...>
Sent: Thursday, August 04, 2005 12:31 AM
Subject: Re: [openwince-list] JTAG cable questions
> On Wed, Aug 03, 2005 at 07:55:48PM -0400, Gregg C Levine wrote:
> > Hello from Gregg C Levine
> > Would someone please take the time to either refute, answer or otherwise
> > comment on these questions:
> > --
> > Q1 The cable described on the portion of the
http://openwince.sf.net/jtag
> > regarding the bricked iPaq, that sent me to the Open WinCE site, is now
> > described as not recommended for regular use. Why is that?
>
> Where is stated that the cable is not recommended?
>
>
> Regards.
>
> --
> +-------------------------------------------+
> | Marcel Telka e-mail: marcel@... |
> | homepage: http://telka.sk/ |
> | jabber: marcel@... |
> +-------------------------------------------+
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> openwince-list mailing list
> openwince-list@...
> https://lists.sourceforge.net/lists/listinfo/openwince-list

On Wed, Aug 03, 2005 at 07:55:48PM -0400, Gregg C Levine wrote:
> Hello from Gregg C Levine
> Would someone please take the time to either refute, answer or otherwise
> comment on these questions:
> --
> Q1 The cable described on the portion of the http://openwince.sf.net/jtag
> regarding the bricked iPaq, that sent me to the Open WinCE site, is now
> described as not recommended for regular use. Why is that?
Where is stated that the cable is not recommended?
Regards.
--
+-------------------------------------------+
| Marcel Telka e-mail: marcel@... |
| homepage: http://telka.sk/ |
| jabber: marcel@... |
+-------------------------------------------+

Hello from Gregg C Levine
Would someone please take the time to either refute, answer or otherwise
comment on these questions:
--
Q1 The cable described on the portion of the http://openwince.sf.net/jtag
regarding the bricked iPaq, that sent me to the Open WinCE site, is now
described as not recommended for regular use. Why is that?
Q2 Is anyone using the JTAG programs for configuring their wireless routers?
It happens that the HRI project, see http://hri.sf.net for details, is well
interested in doing unusual stuff with such hardware, and always in need of
good tool sets.
--
For my own peace of mind I would like to use the JTAG tools to talk to
hardware that's configured for such applications. TI for example makes a
family of such hardware that is on my lists of interesting things.
---
Gregg C Levine yodathejediknight@...