Most people I know think I'm a Nut job as well, which is why I'd prefer
hosting at Savannah to Sourceforge on purely philosophical grounds
myself. I just didn't think you all would want to change the project
name. Maybe they would accept it a is, rules were meant to be broken
after all. I th
As per:
https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly
"we do not accept projects with the word "open" in their name; we
suggest you replace it with free instead, or use another project name of
your choice."
I don't know if this applies to projects under savannah.nong
GDB also had some stuff integrated for "Reverse Debugging". It started
around the April '06 time frame. I don't have any links, this is just
from memory. It supposedly allowed one to step a target "backward" in
time. That's kinda neat and a useful use of trace information. I know
there hav
Thanks for the replies.
Ok, I CAN connect to OpenOCD with Telnet, it threw me because I expected
to see messages like:
> *Warning:no telnet port specified, using default port
> Warning:no gdb port specified, using default port
> Warning:no tcl port specified, using default port *
Bu
0 0 0
> flash bank pic32mx 0xbfc0 0 0 0 0
changed to:
> flash bank pic32mx 0xbd00 0 0 0 $_TARGETNAME
> flash bank pic32mx 0xbfc0 0 0 0 $_TARGETNAME
Any suggestions to get to the point where I can connect with Telnet or
GDB would be greatly appreciated as I am a bit snoo
AG operations
will not operate as expected over ICSP.
There are lots of MIPS chips that have an EJTAG core. An EJTAG
implementation in OpenOCD would be awesome. PIC32 is a nice cheap
platform to develop and test this with.
Strontium
Xiaofan Chen wrote:
> On Mon, May 18, 2009 at 8:58 AM,
>
>> It would be great that openocd can work with
>> PIC32 using JTAG. I think Real ICE, ICD 2 and
>> ICD 3 do not use JTAG for debugging PIC32.
>>
>>
>>
> I am aware of that, that is why I think that it would be easier for
> debugging when we get PIC32 supported.
>
>
Pic32 has 2 deb
ps://lists.berlios.de/pipermail/openocd-development/
>
> If there are other issues to which the maintainers failed to respond,
>
https://lists.berlios.de/pipermail/openocd-development/2009-May/006459.html
I am happy to work on a fix for this one. I just need some direction as
to the mo
rnately flashes the
leds on a beagle in a loop, its loaded by the ROM boot loader in the
OMAP3 over USB. That way when I read registers, I should be able to
verify the contents against my code, based on the state of the leds.
Strontium
proc omap3_WriteDebugRegister { reg_num val } {
# wr
Magnus Lundin wrote:
> Magnus Lundin wrote:
>
>> When I do this for the Beagle i just use
>>
>> # set the current target, should not be nexessary with only one target
>> configured
>> targets omap3.cpu
>> # call tcl functions without the extra target name
>> mem2array dataval 32 [expr "0x54011
dataval 32 [expr "0x54011000 + $reg_num * 4"] 1
"junk" is just crap to make the argc=5 check work, and to align the
variables to the right places in argv[]
What would the most appropriate fix be?
Strontium
Strontium wrote:
> Howdy,
>
> I have
dataval after this, but until i can read
dataval its a bit pointless.
Strontium
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
ters
simultaneously on TDO.
That's JTAG in a nutshell. On top of this, you need to get specs for
chips and work out what the various instruction registers/data registers
do, so you can actually do something useful. That's where it gets
interesting. But JTAG in and of itself i
28 0xb807dbad in parse_config_file (cmd_ctx=0x99bd008) at
configuration.c:118
#29 0xb7fd2708 in openocd_main (argc=3, argv=0xbfadb854) at openocd.c:268
#30 0x08048512 in main (argc=-1211002872, argv=0xf6fef64c) at main.c:39
(gdb)
Strontium
___
FTDI.
Patch attached.
Note: I haven't tested this yet, because SVN Head is segfaulting for
me. More on that later. Yet, I am confident that it will work OK.
Strontium
Index: src/jtag/ft2232.c
===
--- src/jtag/ft2232.c (rev
My problems all were caused by a crappy USB cable.
Problem solved.
Strontium
Magnus Lundin wrote:
> Win, Linux or Mac ??
>
> I have now for a few days tested this with a flyswatter+beagleboard
> under Fedora 10.
> The serial connection stays active when I start and also when I
a better
interface.
I am going to get a new USB cable to rule a bad cable out, but If that
doesn't fix it I will put it down to the flyswatter acting up.
Strontium.
dmesg shows this over and over if the target is unplugged:
[517117.448429] hub 1-2:1.0: Cannot enable port 1. Maybe the USB
apsel 1
reports a correct result, the first time it is called.
any ideas?
Attached are my config script and tcl script for reference
Strontium
Magnus Lundin wrote:
Dirk Behme wrote:
Btw.: Is there an option or a possibility to run a script when I
connect e.g. by telnet?
I'm a little t
eracting with boot loaders, seeing debug messages and the
like.
The commands are independent. The target tty could be disabled (its
still set up, just not being displayed) which just means output from the
target is suppressed, but target_cmd would still try and send data to
the target.
Or someth
strict
aliasing checks. So I manually turn this "feature" off with
-fno-strict-aliasing
Strontium
Dick Hollenbeck wrote:
>> Sorry I have lost most of my enthusiasm, but I don't understand your
>> problem probably. Please explain if you can.
>>
>> Dick
>&g
om SVN, no problems.
Are there any pointers to published docs on the interface? I have
looked around but can't find any.
Strontium
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
21 matches
Mail list logo
