Hi Tomek,
I think the solution with high-level interfaces is to allow them to do their
bitstream magic directly if they have that capability and for low-level
interfaces turn to libswd or other future libraries for other transports. I
have doubts about the feasibility of trying to make most high-
Hi Tomek,
I have zero prior experience with the FT2232 so I took a very brief scan of
its driver code. I get the feeling that this type of device allows fairly
low-level access to interface port pins. If this is true I can see the
logic behind a bitbang function as this provides the generic abst
file.
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 5/7/10 1:16 PM, "Gary Carlson" wrote:
> Hi Øyvind,
>
> Yeah...that actually is the problem. When I run OpenOCD under GDB -- even
> without breakpoints -- the problem goes away completely (natu
I-Cache: disabled
RCLK - adaptive
dcc downloads are enabled
fast memory access is enabled
NAND flash device 'NAND 256MiB 3,3V 8-bit' found
(gdb)
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 5/7/10 1:16 PM, "Gary Carlson" wrote:
> Hi Øyvind,
>
Hi Øyvind,
Yeah...that actually is the problem. When I run OpenOCD under GDB -- even
without breakpoints -- the problem goes away completely (naturally of
course). I have no doubt that your assessment that it is related to timing
is likely correct.
In the absence of not being able to use GDB to
I am just curious if the small problem that I discovered this afternoon can
be duplicated by any other developers/users using other jlink dongles (or
even non-jlink dongles). The first time through a "reset halt" seems to
fail, but subsequently operates flawlessly thereafter.
If anyone has some i
r Korsgaard wrote:
>>>>>>> "Gary" == Gary Carlson writes:
>>
>> Gary> I wanted to see if anyone has any experience trying to upload the
>> Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts
>> (i.e.
>> Gary&g
On 4/27/10 11:52 PM, "Jon Povey" wrote:
> Gary Carlson wrote:
>> I wanted to see if anyone has any experience trying to upload the
>> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts
>> (i.e. AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
>
I wanted to see if anyone has any experience trying to upload the
AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts (i.e.
AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
I have tried erasing and programming the first block of the NAND flash in
every command combination possible wi
Hi Paul,
To be honest, I have been stuck on other projects the last couple months so
I haven't played with the latest build of OpenOCD using the script I created
earlier for the 9G20 much.
If I get a chance, I will try to hook up everything again and see what
happens.
Gary
On 10/21/09 4:37 P
Well...that is great and now everyone knows about your important
contributions to the project. Good for you!
On 9/1/09 5:12 PM, "Duane Ellis" wrote:
> I did *QUITE* a lot for the at91sam7 chips a when we first introduced
> TCL to openocd.
> I also did some more for the STM32 chip.
e may be difficult.
This idea I think has merit for the long term, but maybe leaving things
unchanged for now makes better sense.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
I can now see that I left off a critical detail! :)
Yes, you most certainly can use a TCL set command to accomplish this. The
only issue is you have to spend an inordinate amount of time entering the
values by hand. That in itself is another source for errors -- especially
on processors with la
Hi Øyvind,
Yes, you are absolutely correct that configuration files are a lot of work
to put together. And I might add critical too! :)
One of the things I wanted to do is throw out some ideas for everyone to
think about as possible improvements to this configuration file development
process.
gt; On Monday 31 August 2009, Gary Carlson wrote:
>> The AT91SAM
>> processors have many "knobs" that give the processor a great deal of utility
>> but also provide ample opportunities to mess up things.
>
> You haven't compared them to OMAP chips have you then
Hi Peter,
As requested, you will find the file I developed for the AT91SAM9G20-EK
board I currently have in my possession that I use with a SAM-ICE debugger.
I haven't quite finished it yet, but it seems to be working quite well on my
setup at this stage. Admittedly, I haven't used it yet to debu
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
g around with this file,
> I discoverd that changing the jtag_ntrst_delay back to 200 solved the
> problem. I have included a patch that will just do that.
>
> I hope this will work for you too!
>
> Have fun!
>
> Ferdinand
>
>
> Gary Carlson schreef:
>> H
this at the moment or can I patch this?
Thanks,
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
I am using the same board you are using (except with a J-link debugger
instead of the Olimex) without too many problems.
You may want to consider moving up to the latest OpenOCD software since my
recollection is that a number of problems were fixed between version 1.0 and
2.0 using that interface.
Did you run configure with the --enable-maintainer-mode option set?
Gary
On 8/6/09 8:58 PM, "Alexei Babich" wrote:
> `version.texi': No such file or directory.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lis
e what was minimal neccesary. I tried waiting for 10 us,
> but that did not work. Then I tried the extra cycle in state TEST
> RUN/IDLE and that worked. I think this should not influence other
> targets. It's just one extra cycle of doing nothing before the reset. I
> think
like to
commit the attached patch that was discussed earlier.
This patch in conjunction with the one that Ferdinand developed today for
the arm7_9_common.c file seem to address all the reset problems on the jlink
dongle.
Thanks,
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson
On 8/6/09 2:14 PM, "Ferdinand Postema" wrote:
> I found a solution to my problem. It seems that this module needs one
> clock cycle in state RUN TEST/IDLE between the setting of the vector
> catch and the reset. Then it works perfectly. I tested it with the
> RTCK-feature and on 1 kHz, 2 kHz an
On 7/14/09 7:55 AM, "Alan Carvalho de Assis" wrote:
> Hi Gary,
>
> On 7/13/09, Gary Carlson wrote:
>>
>> I think your board is being held in reset by something other then the J-link
>> dongle. If the board is in reset and the jlink device can't
On 7/13/09 3:39 PM, "Alan Carvalho de Assis" wrote:
>>
>> OK that helps. Here are some additional questions:
>>
>> What is the host-operating system you are using (Windows, Mac OS X, Linux,
>> etc)?
>>
>
> I am running Linux Ubuntu 9.04, gcc 4.3.3, etc :-)
>
>> Does this error show up 10
On 7/13/09 3:06 PM, "Alan Carvalho de Assis" wrote:
> Hi Gary,
>
> On 7/10/09, Gary Carlson wrote:
>>
>> Try the V4 patch.
>>
>
> Same behavior:
>
> # openocd -f interface/jlink.cfg -f board/imx27ads.cfg
> Open On-Chip Debugger 0.2
On 7/12/09 5:01 PM, "Xiaofan Chen" wrote:
>>>
>>> I do not know anything about svn-bisect. But I just used Google for
>>> 5 minutes to locate the svn commit for the above lines.
>>>
>>> 1) r1507 by Zach to fix J-Link reset
>>> https://lists.berlios.de/pipermail/openocd-svn/2009-April/000291.ht
On 7/11/09 6:56 PM, "David Brownell" wrote:
> On Saturday 11 July 2009, Xiaofan Chen wrote:
>> I do not know anything about svn-bisect. But I just used Google for
>> 5 minutes to locate the svn commit for the above lines.
>
> Not relevant to $SUBJECT ... but to "what changed that file",
> and
On 7/11/09 5:38 PM, "Xiaofan Chen" wrote:
> On Sun, Jul 12, 2009 at 8:13 AM, Gary Carlson
> wrote:
>>> I am seeing issues with the str9 using the jlink.
>>> The fix for that is to comment out:
>>> jtag_sleep(5000);
>>> jlink_end_state(TAP
On 7/11/09 2:46 AM, "Spencer Oliver" wrote:
>
>> Based on some initial testing it looks like the what the code
>> thinks the state of the JTAG state machine is verses what it
>> is inside the processor are two different things following reset.
>>
>> There are some other relevant details about
I have no doubt it is
critical to something. Nevertheless understanding the logic behind it, may
help me solve my problem.
Thanks,
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development ma
xecute, wrong result -107 (expected 1)
> Error: jlink_usb_message failed with result=1)
> Error: jlink_tap_execute, wrong result -107 (expected 1)
>
> Any idea?
>
> Regards,
>
> Alan
> ___
> Openocd-development mailing list
&
committing the patch makes
the most sense at this point given what we know today about libusb?
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
jlink-patch-v4.txt
Description: Binary data
___
Openocd-development
> invalid.
> so the usb_close will fail. Also the dev structure is not valid either after
> the usb_reset.
>
> This is why in my patch i search for the device again after the reset.
>
> Cheers
> Spen
It is starting to look like there is no single solution that will fix all
On 7/8/09 5:05 PM, "Xiaofan Chen" wrote:
> On Thu, Jul 9, 2009 at 5:53 AM, Gary Carlson
> wrote:
>> Zach/Spencer/Xiaofan,
>>
>> I did some more experimentation on the latest subversion (2499) and was able
>> to tweak the jlink.c code slightly to pos
;t know is
whether #1 and #4 are. Could you try this out with your dongles and let me
know what happens?
If the patch works, I need to do a little cleanup but I didn't want to focus
on that until I knew for sure whether it would solve the issues at hand.
Thanks,
Gary
Gary Carlson
Gar
cond call returns a valid handle.
Unlike the first handle, however, it is a zombie since anything using it
ends up in a permanent black hole. If I comment out that single line, your
patch works OK.
The problem is I am guessing that statement is critical to Windows opera
oping someone else
on the list can answer is whether the intermittent startup issue plagues
other non-jlink USB dongles.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/8/09 8:18 AM, "Spencer Oliver" wrote:
>> You asked me what the result o
ut if you are interested I could send
that to you and you can try to build gcc with the script. My script is
tested with arm, but it will likely work with others if you want to give it
a try.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/8/09 8:48 AM, "
rror: usb_bulk_write failed (requested=6, result=-13)
Error: jlink_tap_execute, wrong result -107 (expected 1)
.
.
.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/7/09 8:18 PM, "Gary Carlson" wrote:
> Xiaofan,
>
> Your statement is corre
to try it later this evening.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/7/09 8:03 PM, "Xiaofan Chen" wrote:
> On Wed, Jul 8, 2009 at 10:59 AM, Gary Carlson
> wrote:
>> Hi Xiaofan,
>>
>> The second part of the patch is
will be back.
Other then the "reset halt" command being broken, my V8 debugger works well
and I have experienced no startup failures since. As for the "reset halt"
problem I am trying to find out what is causing that.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
reference point for everyone, the at91sam9G20 I am using is based
on an arm926ejs core.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/7/09 4:59 AM, "Spencer Oliver" wrote:
>>>>> For info this breaks my v5 and v6 jlinks (tested stm32)
alid mode value encountered 0
Error: cpsr contains invalid mode value - communication failure
I just started looking at in more detail.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/7/09 8:42 AM, "Øyvind Harboe" wrote:
> Here is a patch o
or
a larger issue with the j-link code.
Thanks,
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo
u rule out libusb.
As for using USBMon, I can't disagree that it is hard to use and is
deficient compared to a true hardware protocol analyzer. I wouldn't waste
my time with that.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/5/09 6:41 PM, "Xi
re version of USB does your host system have (USB 1.0 or USB
2.0)?
Anyway some things to think about.
Gary
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
On 7/5/09 3:46 PM, "Xiaofan Chen" wrote:
> On Mon, Jul 6, 2009 at 6:16 AM, Xiaofan Chen wro
> Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b,
> part: 0xba00, ver: 0x3)
> Info : JTAG Tap/device matched
> Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020,
> part: 0x6414, ver: 0x0)
> Info : JTAG Tap/device matched
>
&
don't want to do is break it for someone else through
unintended consequences.
The second version of this patch that I am working on will hopefully reduce
the failure rate from 2% to zero. I will try to get that out either today
or tomorrow if my own testing proves fruitful.
Gary Carlson
Ga
_read failed (requested=1, result=-32)
.
.
.
After doing some troubleshooting I found the cause. The attached patch
should correct this behavior.
Sincerely,
Gary
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
jlink_patch.txt
Description: Binary
51 matches
Mail list logo
