On Mar 15, 2012 3:15 AM, "simonqian.openocd"
wrote:
>
> Yes, I know how SRST should not be processed in DAP, but make the
> change you mentioned is too large for me to handle in OpenOCD. And it
> also risky because it affect too much in OpenOCD.
Ok then lets do it as you proposed if its already w
On Mar 15, 2012 4:32 AM, "Peter Stuge" wrote:
>
> Tomek CEDRO wrote:
> > I am a bit afraid that my great ideas on automatic error handling and
> > enqueueing longer operation sequences are anyway going to be broken
> > because of the USB latency bottleneck :-(
> >
> > Were maximum FT2232H transfer
Tomek CEDRO wrote:
> > in practise it will be tens of ms
>
> Ugh, this will not help as we need to evaluate results very often
> as you noted. Also this would vary across different platforms...
Yep.
> Ill see how things could be speeded up using TAR autoincrement
> and sticky errors handling s
> So we should place that reset implementation using interface bitbang..?
I currently use interface_jtag_add_reset(0, new_srst); to control srst in SWD
mode.
Although not best modular, but works with the least and safest patch.
> So there is some code uploaded and executed on the target and that
On Mar 15, 2012 8:30 AM, "Peter Stuge" wrote:
> > Ill see how things could be speeded up using TAR autoincrement
> > and sticky errors handling so we write large data in bursts of
> > few kilobytes at once (1k or 64k max for mpsse per command)...
>
> That's great if possible. This is why I rant so
OK, I have tested this patch with my other SWD patches, it works well.
But another code should be fixed too.
I want to query for how to fix it.
on "reset init" command, init_reset procedure in startup.tcl will be called:
proc init_reset { mode } {
jtag arp_init-reset
}
and then jim_jtag_arp_init_r
Yup, the easiest way to test thing without changing stuff with dependencies
in multiple places would be simply to create a wrapper for existing
function that will call original with _jtag suffix or new one with _swd
suffix, just as I did in case of memapreadu32. Changing functions inline
would prod
Tomek CEDRO wrote:
> On Mar 15, 2012 8:30 AM, "Peter Stuge" wrote:
> > > Ill see how things could be speeded up using TAR autoincrement
> > > and sticky errors handling so we write large data in bursts of
> > > few kilobytes at once (1k or 64k max for mpsse per command)...
> >
> > That's great if
On 15.03.2012 16:04, Peter Stuge wrote:
> Tomek CEDRO wrote:
>> On Mar 15, 2012 8:30 AM, "Peter Stuge" wrote:
Ill see how things could be speeded up using TAR autoincrement
and sticky errors handling so we write large data in bursts of
few kilobytes at once (1k or 64k max for mpsse
So I implement it as below:
First add swd_init_reset:
int swd_init_reset(struct command_context *cmd_ctx)
{
int retval = adapter_init(cmd_ctx);
if (retval != ERROR_OK)
return retval;
LOG_DEBUG("Initializing with hard SRST reset");
jtag_add_reset(0, 1);
jtag_add_reset(
Mathias K. wrote:
> > A Cortex-M3 (LPC1343 or STM32) *development board* is cheaper than an
> > FTDI *chip* actually.
>
> But not that much:
>
> http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=75&title=FT4232H+Module
The FTDI module costs 160% of the 15
simonqian.openocd wrote:
> I'm doing some tests, if it's OK I'll format a new patch.
I think it looks fine. Am looking forward to the patch.
I would suggest changing the Tcl command from jtag to e.g. transport
while keeping backwards compatibility but outputing a warning
whenever someone uses the
On 03/14/2012 07:24 PM, salvador wrote:
> Hello
>
> If i try the command " mdw addr n " with n greater than 1024 the data
> displayed is wrong from 1025 onward.
>
>
>
> The bug is located in mips32_pracc.c, in function mips32_pracc_read_mem32
>
>
> About line 364:
>
>
> count -=
On Thu, Mar 15, 2012 at 6:44 PM, salvador wrote:
> On 03/14/2012 07:24 PM, salvador wrote:
> 1.- There is no call to mips32_pracc_read_mem32() in
> mips_m4k_read_memory().
Yes, there is. It is called implicitly, by mips32_pracc_read_mem().
Anyway, count parameter is propagated.
Looking in the m
On 5 March 2012 10:30, Spencer Oliver wrote:
> On 17 February 2012 15:55, wrote:
>> This is an automated email from Gerrit.
>>
>> Robert Jarzmik (robert.jarz...@free.fr) just uploaded a new patch set to
>> Gerrit, which you can find at http://openocd.zylin.com/467
>>
>> -- gerrit
>>
>> commit 3
This is an automated email from Gerrit.
Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/523
-- gerrit
commit 05b25371a10a4f74ab40064ec24fc6cad85f4057
Author: Mathias K
Date: Thu Mar 15 09:11:19 2012 +0100
gdb_ser
This is an automated email from Gerrit.
Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/524
-- gerrit
commit 906c3b0d3638e71ba823f91341693f393aff0078
Author: Mathias K
Date: Thu Mar 15 14:58:32 2012 +0100
armv7m:
This is an automated email from Gerrit.
Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/525
-- gerrit
commit 0e5f770a2a74ddd981a52d10f6359d2c27642e86
Author: Mathias K
Date: Thu Mar 15 15:25:27 2012 +0100
stm32:
Hi，
> Date: Thu, 15 Mar 2012 19:11:45 +0100
> From: drasko.drasko...@gmail.com
> To: salva...@telecable.es
> CC: openocd-devel@lists.sourceforge.net
> Subject: Re: [OpenOCD-devel] Bug in mips32_pracc_read_mem32
>
> On Thu, Mar 15, 2012 at 6:44 PM, salvador wrote:
> > On 03/14/2012 07:24 PM, sal
19 matches
Mail list logo
