/ What do you mean by Senior developers ?
/
Developers bestowes us with their great acumen.
/ What do you really interpret At the sharp rise, Gerrit was introduced ?
/
# of commits rose from 3 to 30 a week.
I am really not sure to find any correlation between the coming of
gerrit and the
good read ! Thanks.
What do you mean by Senior developers ?
What do you really interpret At the sharp rise, Gerrit was introduced ?
Laurent
http://www.amontec.com
HIGH-SPEED USB JTAG INTERFACE as generic as possible
___
Openocd-development mailing
Hi guys!
I am trying to program an lpc1768 device using an oocdlink
(Ft2232-based) programmer.
Only every other programming works, which is very strange.
After the first programming, the uC seems to be in a lockup state.
After second programming, it always works as a charm.
I'm pretty much
Well, the ARM-JTAG-EW is not an FT2232 device as far as I can tell -- it's
supposed to be a JLink clone for IAR.
I guess the answer is no then. Looks like the right thing is to get a real
JLink. Thanks anyway!
On Tue, Oct 18, 2011 at 1:52 AM, Tomek CEDROtomek.cedro at gmail.com
Hi Spen,
Why using a commercial server and a commercial url for an open source project?
Regards,
Laurent
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi!
Is there a good reason why ft2232_transfer uses bit-by-bit mpsse transfer?
If not, I would be happy to rewrite it to use bytewise transfer, if
the number of bits to be transferred is divisable by 8.
Might make things a *little* bit faster...
Regards,
Ákos
This will be great, Akos.
Also,
Hi,
due to the coming SWD support, I found that the arm_adi_v5 has
dependencies to the jtag subsystem. To preserve the performance I
changed the interface to the transport layer. Both, dap_queue_ap_write
and dap_queue_ap_read gets a pointer to a data array not a single value.
The adi_v5_jtag
I can take a look at this as I'm finishing to solder a hardware that I
will finish the SWD implementation in upcoming days, but I would
rather not change interface/jtag/transport layer until SWD is done.
When its done and working then we can change internals, otherwise we
will have two different
On Wed, Jul 13, 2011 at 10:55 PM, Xiaofan Chen xiaofanc at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Under Linux, ftd2xx 1.04 (based on libusb-1.0.8) does not seem to offer
// any advantage than libftdi (tested with 0.19)
/
This is the same as reported
Hello!
I'm trying to embed a FT2232D based programmer into my board with a
STM32 (Cortex-M3 MCU).
I want the programmer to be compatible with jtagkey, so I looked at
schematics of compaible designs.
I noticed that while the JTAG signals (TCK, TDI, TDO, TMS) are only
buffered when
your JTAG interface synchronized with the
target frequency.
Regards,
Laurent Gauch
http://www.amontec.com/jtagkey.shtml
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
On 6 July 2011 13:17, Spencer Oliver spen at spen-soft.co.uk
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Openocd did work ok for wfi as long as the jtag clock was slow enough.
// However this was broken in HEAD last time i tested it - it has been on
// my look at list
On 6 July 2011 13:52, Laurent Gauch laurent.gauch at amontec.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Are you sure your Target JTAG interface is active in your low power mode ?
/You seams to be right (even if I have not found this information in
the user manual
Greetings all,
In the past few days I have been trying to get my USB Blaster clone
(called USB Blaster mini) to work with OpenOCD from the latest git
tree (762ca59dd5cbe70026234d549bb5f5ac1a05d5b4
On Fri, 24 Jun 2011 16:32:54 +, Tomek CEDRO wrote:
Cool, I will add new field into layout structure that will indicate
forbidden bits to bitbang, this field will be zero by default so all
bits are allowed, driver author can add some value of this field to
the specific layout - that value AND
The best is to standardize at a lower level ... and to forget the idea to have
the possibility to bitbang from the TCL of the openocd.
/
//That's as for the SWD, we have to standardize some function call in the
ft2232, and avoiding bitbang access from higher-level.
//
//That's not simple to
Steve Bennett wrote:
On 21/06/2011, at 5:22 PM, Steve Bennett wrote:
On 21/06/2011, at 5:18 PM, Laurent Gauch wrote:
Steve Bennett wrote:
On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote:
On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote
/ On Thu, Jun 23, 2011 at 1:03 PM, Steve Bennett steveb at workware.net.au
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// On 23/06/2011, at 8:59 PM, Øyvind Harboe wrote:
//
// I don't think this is sufficient, as it will put up warnings on some
// other platforms
Simple and true :-) Each interface has its own config file anyway, so
this file can contain also signal definition for that interface. If
interface has no signals defined, no signals will be defined, so there
is no worry.
Here we have to select between Simple and Safe !
We know that a large
/My objective is not to block feature.Never,never,never ... But we have
//to avoid any trouble in generic ft2232 driver regarding specific layout.
//That's all.
//Your TCL bitbang will control the port of the FTDI from an higher level
//than FT2232.c. OK but you TCL bitbang is specific to the
Steve Bennett wrote:
On 21/06/2011, at 3:59 PM, Laurent Gauch wrote:
On 21/06/2011, at 1:07 AM, Laurent Gauch wrote:
/ // / On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au
https://lists.berlios.de/mailman/listinfo/openocd-development wrote
Xiaofan Chen wrote:
On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote:
But are you sure to have the correct libusb version. On linux and mac, the
libusb is the kernel driver for the d2xx.
This has been discussed before and I think in this case an exception should
Steve Bennett wrote:
On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote:
On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote:
But are you sure to have the correct libusb version. On linux and mac, the
libusb is the kernel driver for the d2xx.
This has been
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
--
interface_signal add led 8000
interface_signal add led 8000
There are no signals
Sergey Lapin wrote:
On Mon, Jun 20, 2011 at 4:44 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
only one transport option; autoselect 'jtag'
interface_signal list
interface_signal list
Interface Signal Name |Mask| Value
/ On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote:
//
// On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au
Hi Øyvind Harboe,
Please refrain from shouting(using uppercase). It's more likely
that people will ignore your email than read it.
Thank you for the advice.
As a maintainer, I'm not terribly excited about bitbanging and other
non-CPU related protocols. Projects like UrJTAG pursue
this
On Mon, 20 Jun 2011 16:37:32 +, Tomek CEDRO wrote:
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it
is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
Yes, easy but dangerous, because you are layout specific !!!
Tomek CEDRO wrote:
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use
try to be objective and to help the discussion.
Regards,
Laurent Gauch
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 HIGH-SPEED USB JTAG INTERFACE ADAPTERS CABLES
Best regards! :-)
Tomek
btw. maybe automatically executing autoreconf for libswd submodule
will fix the problem you mentioned
Hello Laurent! :-)
On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch laurent.gauch at amontec.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ But before to close the handle we should still be able :
// -1- to tristate signal High-Z via all the out enable signals used
On Thu, Jun 9, 2011 at 10:57 PM, Andreas Fritiofson
andreas.fritiofson at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ ft2232_init really refers to init of the openocd driver, while
// ft2232_init_{libftdi,ftd2xx} refers to init of the ftdi subsystem
On Thu, Jun 9, 2011 at 10:17 PM, Tomek CEDRO tomek.cedro at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Hello Laurent! :-)
//
// On Thu, Jun 9, 2011 at 6:21 AM, Laurent Gauch laurent.gauch at amontec.com
https://lists.berlios.de/mailman/listinfo/openocd
/ Hello Andreas :-)
//
// On Thu, Jun 9, 2011 at 11:30 PM, Andreas Fritiofson
// andreas.fritiofson at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// I have created simple quit() that sets all port pins high and as input
// (mpsse command 0x80 0x82) but that
On Thu, Jun 9, 2011 at 11:46 PM, Andreas Fritiofson
andreas.fritiofson at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Setting the FTDI pins to Hi-Z is not necessarily the same as setting the
// pins in the JTAG connector to Hi-Z. There is arbitrary
allowing FT chip also to work with SWD and possibly any
other transport. For this kind of good design there _is_ universal
behavior (read more below) :-)
Also note what Laurent told:
On Tue, Jun 7, 2011 at 9:34 AM, Laurent Gauch laurent.gauch at amontec.com
https://lists.berlios.de/mailman/listinfo
/ / Do you have any other ideas on what should be done on ft2232_quit()
// // except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I
// // can see he is already working out the subject :-)
// /
//
// What problem is setting pins to a default state on exit supposed to
// solve? Are
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 08:42 Thu 09 Jun , Laurent Gauch wrote:
On 15:25 Tue 07 Jun , Laurent Gauch wrote:
/
// /If our ft2232.c patches are not merged quickly, Amontec Team will
certainly
// // come with a new specific jtagkey.c API driver
Am 06/10/2011 09:33 AM, schrieb Laurent Gauch:
/
// / Do you have any other ideas on what should be done on ft2232_quit()
// // except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I
// // can see he is already working out the subject :-)
// /
//
// What problem is setting pins
/
// I suggest to drop this patch and merge a simpler fix for the problem
// adressed by this patch. Only a few lines of code would need to change.
//
//
/Attached is such a patch. The benefit over Tomek's patch is that it frees
not only the allocated buffer but also closes the ftdi handle (as
Free the buffer before return. Also check the malloc return value.
Perhaps it's not a good idea to exit() on error, but it's in line with the
rest of the function.
Strange thing with this function is that the allocated buffer doesn't seem
to be used for anything. The data read into it doesn't
On 15:25 Tue 07 Jun , Laurent Gauch wrote:
/
// /If our ft2232.c patches are not merged quickly, Amontec Team will
certainly
// // come with a new specific jtagkey.c API driver instead of the ft2232.c
JTAG
// // driver.
// // The advantage with a specific Amontec JTAGkey API driver
Hi Michael,
Am 06/06/2011 02:10 PM, schrieb Laurent Gauch:
/ Yes, this is to decouple the open and init (open the handle, init
// the associated specific layout).
/
Is there case where open is used without init, or init without open?
Actually no. But in the ft2232.c we could have
Hi Tomek,
First, thank you for giving objective comments on the patch. Much
appreciated from you.
(Much better than the Student code galore from Peter)
Hello Laurent,
Sorry if my comment seems not meritoric, I am not mentioning about
coding style because this leaves a lot to tell in case of
/ Please just use goto to handle errors.
//
// /*When we talk coding style with students, the first comment I have is :
// DO NEVER USE GOTO STATEMENT BUT USE IF ELSE IF ...
/
I'm afraid that's not only doing your students a disservice, but also
their future employers.
Sorry, but I prefer
Hi Andreas,
Thank you for your comment.
It doesn't build. Leftover variable no longer used.
minor issue
Apart from that it seems OK from my limited review. I could agree with the
others that it looks like a needlessly complex fix for a simple missing
free. Maybe there's a bigger picture here
/If our ft2232.c patches are not merged quickly, Amontec Team will certainly
// come with a new specific jtagkey.c API driver instead of the ft2232.c JTAG
// driver.
// The advantage with a specific Amontec JTAGkey API driver in openocd, will be
// to see our patches merged in the minute,
Hello again :-)
I have reviewed the patch.
The old source code had 3 functions ft2232_init() that can call
ft2232_init_libftdi() or ft2232_init_ftd2xx() depending on a ft2232
ftdi communication library available. This is pretty simple and
coherent.
Yes simple, but bugged !!!
The new
Tomek CEDRO wrote:
/ The new source code (after patching) have 6 functions doing almost
// the same: ft2232_init_ftd2xx(), ft2232_open_ftd2xx(),
// ft2232_init_libftdi(), ft2232_open_libftdi(), ft2232_init_sub(void),
// ft2232_init() and the header update ;-)
/
Student code galore.
Did
On Wed, Jun 1, 2011 at 9:23 PM, Peter Stuge peter at stuge.se
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Indeed what you get with good use of goto. The rule is basically to
// only goto in the forward direction within a function. It's very
// simple, and it can make
:-)
Regards,
Laurent
Spencer Oliver wrote:
On 27/05/2011 16:51, Laurent Gauch wrote:
Hi,
You're right,
the last version from git cannot be compiled from my mingw too, but can
be compiled with my cygwin ;-)
But with mingw, i do not have the same error as you, but related to
tclsh, strange
I will try again today, but esterday I compiled openocd d2xx on cygwin
and on mingw for 32bits and 64bits without any error. Everything fine !
Note: the problem we meet during April is now gone - thank you Spencer
Oliver.
Regards,
Laurent
http://www.amontec.com
Hi,
You're right,
the last version from git cannot be compiled from my mingw too, but can
be compiled with my cygwin ;-)
But with mingw, i do not have the same error as you, but related to
tclsh, strange .
Regards,
Laurent
___
Hi Rodrigo,
There are nothing really difficult here !
If you get a look at the jtagkey init , you may see how to drive the
SRST and TRST as gpio. Do the same for a read ;-) !
The SRST and TRST are controlled from an higher level than the low jtag
driver layer :-)
Best regards,
Laurent
Yes, there are patches.
Please merge the Sebastien's patch.
Now about 4-weeks this patch wait to be merged.
Laurent
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Øyvind Harboe wrote:
Please repost the patch.
https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html
Merge it !
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Øyvind Harboe wrote:
Loose the attitude.
What ?
On Mon, May 16, 2011 at 9:14 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
Øyvind Harboe wrote:
Please repost the patch.
https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html
Merge
Øyvind Harboe wrote:
https://lists.berlios.de/pipermail/openocd-development/2011-April/018780.html
I see that this is not actually formulated as sequence of git patches.
Please formulate it as a patch and repost it. That will improve your chances
of a review.
On 11/05/11 13:54, Laurent Gauch wrote:
/ Hi Sébastien,
//
// Amontec is working on the SWD CTJTAG support on JTAGkey-3 generation.
//
// Could you please let me know where did you get the info :
//
// TMS is used as a clock while holding TCK at '1' really needs to be
// added.
//
//
// Best
interface ( as 30MHZ for a Amontec
JTAGkey-2 ).
The frequency will be controlled by the target via the RTCK signal. So
no need to be worry about the frequency of the processor, regarding post
init reset procedure ...
Laurent Gauch
http://www.amontec.com/
Amontec JTAGkey-2 : High speed USB JTAG
Hello Drasko,
The end goal it's to have a safe state of the used JTAG adapter at the
end of the executable file.
With this patch = Fix: Correctly exit function: ft2232_init when an
error occurred
I wish correct the status at the end of ft2232_init function when an
error occured.
At
I've noticed strange behaviour in initialization with TI OMAP4430 and
Freescale iMX53 using Amontec JTAGKEY. Even typing keys on OpenOCD shell
was very very slow.
I didn't investigate too much the causes. Anyway this patch fix it.
Signed-off-by: Luca Ellero lroluk at gmail.com
I'm not looking for something that works in all circumstances. I just
want it to be the *same* across all interfaces.
The correct long term solution would be to have *no* default speed
and just put up an error message if the script doesn't specify it.
IMHO.
For me the correct is :
1. -init- fix
/ I'm not looking for something that works in all circumstances. I just
// want it to be the *same* across all interfaces.
//
// The correct long term solution would be to have *no* default speed
// and just put up an error message if the script doesn't specify it.
// IMHO.
/For me the correct
A tip that might be applicable:
break the patch apart in multiple patches.
The first patch would rearrange the code, but essentially leave the
entire execution and behavior unchanged(bugs included).
The Sebastien's patch is already very small and is the 'rearrange the
code' part. There
Øyvind Harboe wrote:
Did you read the patch ?
No. I'll leave it to others to work on the ft2232 driver.
So if you did not read the patch, why did you comment it !
I'm just trying to give him some general advice on how to
best solicit the review / help from others on the list as he
Sounds like an awfully complicated solution to what's going
on all the time in terms of a cleanup problem.
Right, this is not the IDEAL solution.
But openocd mechanism concerning jtag adapter init and jtag adapter
init/quit is not IDEAL too !
The better case for jtag adapter would be to
Øyvind Harboe wrote:
On Wed, Apr 13, 2011 at 2:57 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
If someone else on the list looks at your patch and thinks it is a good
solution to the problem then that would help too.
Yes, this is a good solution.
So, you can merge
The immediate work-around:
remove the ; from your configure file at line
14208 - 14245 - 14315 - 14348 - 14698 - 14726
or the like!
Laurent
http://www.amontec.com
Rodrigo Rosa wrote:
o cloned from git, and then i ran these commands:
./bootstrap
./configure --enable-mantainer-mode
https://lists.berlios.de/pipermail/openocd-development/2011-April/018646.html
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
fields[0].in_value = spracc_in instead fields[0].in_value = NULL, the communication USB to Amontec JTAGkey dongles could
be slower, because the TDO must be returned back to host computer, and more USB access will be generated.
Laurent Gauch
http://www.amontec.com
http://www.amontec.com
Drasko DRASKOVIC wrote:
On Thu, Apr 7, 2011 at 1:09 PM, Laurent Gauch laurent.ga...@amontec.com wrote:
/ drasko.draskovic at gmail.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
// Hi all,
// I have one general question regarding OpenOCD scans.
//
// What
Last GIT has configure file corrupted.
; at line 14208 - 14245 - 14315 - 14348 - 14698 - 14726
do you need patch ?
Regards,
Laurent
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec JTAGkey-2 : low-cost High-Speed USB JTAG cable interface
protocol needs to be used.
Nice idea.
I understand yet.
Laurent Gauch
http://www.amontec.com
On Wed, 2011-04-06 at 18:23 +0200, Øyvind Harboe wrote:
/ If you want the community to accept your patch, then not only
// do you need to pass all the GPL hurdles, but the community
// must
On Thu, Apr 7, 2011 at 5:19 PM, Peter Stuge peter at stuge.se
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Laurent Gauch wrote:
// Last GIT has configure file corrupted.
// ; at line 14208 - 14245 - 14315 - 14348 - 14698 - 14726
//
// do you need patch ?
//
// If you
The target board is s3c2440.
the log is:
(gdb) monitor jtag_khz 3000
3000 kHz
(gdb) load u-boot
Loading section .text, size 0x2044c lma 0x33f8
Loading section .rodata, size 0x1d54 lma 0x33fa044c
Loading section .rodata.str1.4, size 0x7cb7 lma 0x33fa21a0
Loading section .data, size 0x1558 lma
Hi Andy,
Thank you.
Have a nice day.
Regards,
Laurent
http://www.amontec.com
Andrew Lyon wrote:
Hey Laurent,
The url in your sig is wrong, just thought I'd let u know.
Andy
On 06/04/2011, Laurent Gauch laurent.ga...@amontec.com wrote:
The target board is s3c2440.
the log is:
(gdb
is in the shift regsiter itself !
For me, you are misunderstanding the SPrAcc flag and PrAcc bit.
Hoping to help.
Regards,
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec USB JTAG Cable solutions Amontec JTAGkey Amontec JTAGkey-2
Amontec JTAGkey-2P
BR,
Drasko
?
Basically, do we check PrAcc in CONTROL reg before or after FASTDATA
transaction ?
BR,
Drasko
Before.
Reading Figure 6-16 Write Processor Access Example, the PrACC must be
checked first.
Regards,
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec USB JTAG Cable
not have successfully completed.
Regards,
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec USB JTAG Cable solutions Amontec JTAGkey Amontec JTAGkey-2
Amontec JTAGkey-2P
___
Openocd-development mailing list
Openocd
integrate the ULINK in OPEN SOURCE PROJECT as openocd.
See http://embdev.net/topic/129290 from an other Martin.
Regards,
Laurent Gauch
http://www.amontec.com
http://www.amontec.com/jtagkey.shtml
Amontec High-Speed USB JTAG Cable solutions Amontec JTAGkey JTAGkey-2 JTAGkey-2P
On Mon, Apr 4, 2011 at 7:51 PM, Øyvind Harboe oyvind.harboe at zylin.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Any objections to merging 1,2 and 4?
//
// I think #3 needs more discussion or cool-off. My objection is
// that we don't know why this makes things
Drasko DRASKOVIC wrote:
On Tue, Apr 5, 2011 at 9:01 AM, Laurent Gauch laurent.ga...@amontec.com wrote:
On Mon, Apr 4, 2011 at 7:51 PM, Øyvind Harboe oyvind.harboe at zylin.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Any objections to merging 1,2 and 4
Amontec Team thoughts are with David's family.
We had a lot of great technical support with David.
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
Well done.
Regards,
Laurent Gauch
http://www.amontec.com
Drasko DRASKOVIC wrote:
Hi all,
here is a set of patched (separeted by the logical changes they
introduce) that :
1) Correct endianess for big endian targets
2) Correct while(1) loop waiting for PrAcc to be 1
3) Change FASTDATA
The openocd server does NOT close the handles after an error was
detected. (ft2232 handle)
This makes the future session of openocd not working, or returning other
message like error: couldn't read enough bytes from FT2232 device (0
xxx) :-(
Also, this kind of message is close to the one
Hi Drasko,
Hi Andy,
thank you for these tests, it is very helpful. The problem you have
can be easily solved by applying David Claffey's patches.
I see that mips32_pracc_fastdata_xfer() works well for you - I'll
take a look why it does not work for me and elaborate on the list.
Also, I can
be different on a PIC32MX or other MIPS with the
same eJTAG interface... ;-)
Regards,
Laurent Gauch
http://www.amontec.com Amontec JTAGkey-3 coming soon ! Generic USB JTAG CJTAG
SWD SWO serial wire debug interface 1.5V 1.8V 2.5V 3.3V 5V auto-sense
protected IOs With RTCK support
maximum 30Mhz
enough bytes from FT2232 device (0
5) still persist.
Can you point me how to override the problems with compilation with
Amontec driver ?
Best regards,
Drasko
On Thu, Mar 17, 2011 at 5:23 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
Try with d2xx Linux driver attached.
Compile
the same with Amontec JTAGkey D22X WHQL certified driver you found at
http://www.amontec.com/download/amontec-jtagkey-driver-d2xx-20091124.zip
Regards,
Laurent Gauch
http://www.amontec.com
Amontec JTAGkey-3 coming soon !
Generic USB JTAG CJTAG SWD SWO serial wire debug interface
1.5V 1.8V 2.5V
On Thu, Mar 17, 2011 at 2:50 PM, Laurent Gauch
laurent.gauch at amontec.com
https://lists.berlios.de/mailman/listinfo/openocd-development wrote:
/ Hi Mathias K.,
//
// You have this command buffer
//
// 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 02 03
//
// 4b 02 01 / TMS shift no read
, in this case it is a
trouble in the libftdi . If the same some trouble in the higher JTAG
level in openocd source.
Regards,
Laurent Gauch
http://www.amontec.com
Amontec JTAGkey-3 coming soon !
Generic USB JTAG CJTAG SWD SWO serial wire debug interface
1.5V 1.8V 2.5V 3.3V 5V auto-sense
Drasko DRASKOVIC wrote:
On Thu, Mar 17, 2011 at 3:19 PM, Laurent Gauch
laurent.ga...@amontec.com wrote:
I do not need the complete debug log file for sure :-) but try to cut it
with 2 to 4 command queue execute before your trouble.
I am thinking of a corrupted mpsse command just before your
---
src/jtag/core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index d7e1cce..68c1257 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -871,9 +871,16 @@ static int jtag_reset_callback(enum jtag_event event, void
Øyvind Harboe wrote:
On Thu, Mar 3, 2011 at 3:29 PM, Laurent Gauch laurent.ga...@amontec.com wrote:
---
src/jtag/core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index d7e1cce..68c1257 100644
--- a/src/jtag/core.c
Øyvind Harboe wrote:
Anyway, adding delays on JTAG level should be corresponding to generating
some TCK in stable state, EVER.
We never should have to add ANY 'software' delay in the JTAG level , if we
do (and I think we do) this is the better way to get instable ISP.
the delay is
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
-uint8_t buf[3];
-uint32_t bytes_written
Everything I've tried works well... Individual sector erase, multiple sector
erase up to the full device, image writes, image writes with auto-erase, gdb
debugging through Eclipse.
Thanks for your work on this!
Mike Lake
What version of OpenOCD do you use ?
Regards,
Laurent Gauch
http
Here I have objection.
Adding delay by flushing queue is not a good implementation, since the
flush of the queue will have different timing regarding the JTAG probe used:
- With Amontec JTAGkey USB full-speed a flush will be around 1-2ms
- With Amontec JTAGkey-2 USB High-speed a flush will be
1 - 100 of 222 matches
Mail list logo
