On Monday 18 May 2009, Dirk Behme wrote:
>
> > Any thoughts on how OpenOCD could be made clearer at this point?
>
> Some additional printfs and/or error messages? E.g.
>
> - When init is executed 'automatically' at startup:
>
> printf("Info: init successfully done\n");
>
> - When you try to do
Øyvind Harboe wrote:
> On Mon, May 18, 2009 at 7:55 PM, Dirk Behme wrote:
>> Ųyvind Harboe wrote:
>>> You can't use "target create" on the telnet command line
>>> because it is after "init". If "init" is not on the command
>>> line, OpenOCD runs it before launching the telnet
>>> server.
>> Ah, t
On Mon, May 18, 2009 at 7:55 PM, Dirk Behme wrote:
> Ųyvind Harboe wrote:
>>
>> You can't use "target create" on the telnet command line
>> because it is after "init". If "init" is not on the command
>> line, OpenOCD runs it before launching the telnet
>> server.
>
> Ah, that explains a lot! ;) W
Øyvind Harboe wrote:
> You can't use "target create" on the telnet command line
> because it is after "init". If "init" is not on the command
> line, OpenOCD runs it before launching the telnet
> server.
Ah, that explains a lot! ;) Will try it.
Thanks
Dirk
_
You can't use "target create" on the telnet command line
because it is after "init". If "init" is not on the command
line, OpenOCD runs it before launching the telnet
server.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_
Øyvind Harboe wrote:
> You have to create the target before the init command.
>
> One could talk about allowing targets to be created/deleted
> on the fly, but OpenOCD isn't at that stage today.
>
>
> This works:
>
> openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg
> -c "ta
On Sunday 17 May 2009, Duane Ellis wrote:
> david> Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example)
> david>defines a global AT91C_ID ... which strongly presumes that there's
> david> only one at91 family chip, since those IDs vary between chips.
>
> In general, atmel has a singl
You have to create the target before the init command.
One could talk about allowing targets to be created/deleted
on the fly, but OpenOCD isn't at that stage today.
This works:
openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg
-c "target create omap3.cpu cortex_m3 -endian l
Øyvind Harboe wrote:
>> So this *does* work :)
>>
>> Looks like a Cortex configuration/environment issue then.
>
> Strange indeed.
>
> Can you reproduce it w/your target and the dummy driver?
openocd -s lib/openocd/ -f interface/dummy.cfg -f board/ti_beagleboard.cfg
> version
Open On-Chip Debu
> So this *does* work :)
>
> Looks like a Cortex configuration/environment issue then.
Strange indeed.
Can you reproduce it w/your target and the dummy driver?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
__
Øyvind Harboe wrote:
> On Sun, May 17, 2009 at 8:02 PM, Dirk Behme wrote:
>> Ųyvind Harboe wrote:
>>> Strange indeed. Parsing works here...
>> Yes, I believe this ;)
>>
>> The big question is what might be different for me.
>>
>> From your last mail, you use 'at91eb40a' CPU configuration? Maybe th
duane> [about stuff in tcl/memory.tcl]
david> Hmm, I asked about this sort of thing not long ago:
I've been buried with other tasks and not paying attention much on the
list for a while.. Other things had to take priorities.
david> Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,
For reference, this little utility:
# mrw: "memory read word", returns value of $reg
proc mrw {reg} {
set value ""
ocd_mem2array value 32 $reg 1
return $value(0)
}
works fine in my tree, which is still at r1793.
... and yes, I'd be all for removing that hack which
morphs
On Sun, May 17, 2009 at 8:02 PM, Dirk Behme wrote:
> Ųyvind Harboe wrote:
>>
>> Strange indeed. Parsing works here...
>
> Yes, I believe this ;)
>
> The big question is what might be different for me.
>
> From your last mail, you use 'at91eb40a' CPU configuration? Maybe the init
> scripts for this
On Sunday 17 May 2009, Duane Ellis wrote:
> FYI - I wrote the original JimTCL memory functions here last year, sadly
> my documentation level sort of sucks eh?
Documentation? Didn't even know that tcl/* stuff existed. :)
There aren't even any users of the tcl/* stuff in any of
the existing cfg
Øyvind Harboe wrote:
> Strange indeed. Parsing works here...
Yes, I believe this ;)
The big question is what might be different for me.
From your last mail, you use 'at91eb40a' CPU configuration? Maybe the
init scripts for this do some magic which is missing for me? What
scripts do you source
Strange indeed. Parsing works here...
> ocd_mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
Target not examined yet
mem2array: Read @ 0x54011000, w=4, cnt=1, failed
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
__
Øyvind Harboe wrote:
>> -- cut --
>> > version
>> Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800
>> > omap3.cpu mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
>> > ocd_mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
>> invalid command name "ocd_mem2array_dataval"
>
> ocd_mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
FYI - I wrote the original JimTCL memory functions here last year, sadly
my documentation level sort of sucks eh?
The intent was to *NEVER* really expose "ocd_mem2array" that was a
builder function. Based on my quick read of what you
> -- cut --
> > version
> Open On-Chip Debugger 0.2.0-in-development (2009-05-17-07:51) svn:1800
> > omap3.cpu mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
> > ocd_mem2array dataval 32 [expr "0x54011000 + 0 * 4"] 1
> invalid command name "ocd_mem2array_dataval"
> called at file "command.c"
Zach Welch wrote:
> On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote:
>>> So some progress, but nothing more ;)
>>>
>>> (all: Above error is from TCL script containing "ocd_mem2array
>>> romtable_cid 32 [expr ($debugbase&0xF000) + 0xFF0] 4")
>>>
>>> Do you have any special patches or do
On Sun, 2009-05-10 at 22:31 +0200, Magnus Lundin wrote:
> >
> > So some progress, but nothing more ;)
> >
> > (all: Above error is from TCL script containing "ocd_mem2array
> > romtable_cid 32 [expr ($debugbase&0xF000) + 0xFF0] 4")
> >
> > Do you have any special patches or do I need any speci
>
> So some progress, but nothing more ;)
>
> (all: Above error is from TCL script containing "ocd_mem2array
> romtable_cid 32 [expr ($debugbase&0xF000) + 0xFF0] 4")
>
> Do you have any special patches or do I need any special configure
> option to enable (& compile) tclapi.c?
>
Standard bui
On Sun, 2009-05-10 at 15:20 +0200, Dirk Behme wrote:
[snip]
> As already mentioned, looking into the code: ocd_mem2array is
> registered in tclapi_register_commands() in tclapi.c. But: It seems to
> me that tclapi_register_commands() isn't called anywhere, and even
> worse, tclapi.c isn't compi
Magnus Lundin wrote:
> Dirk Behme wrote:
>> Magnus Lundin wrote:
>>> Hi
>>> Rev 1547, Added two commands that just returns values in hex, good for
>>> scripting.
>>>
>>> >dap baseaddr
>>> >dap apid
>>>
>>> Next I started playing with Tcl scripts that scans the ROM table and
>>> installed compo
25 matches
Mail list logo
