Hi, list! I'm working on a project with 2 arm946es CPUs, connected in a JTAG chain.
Startup code looks like:
set CHIPNAME np10
set CPUTAPID 0x41059461
set CHIP_CORES {cpu dsp}
foreach core $CHIP_CORES {
# CPU jtag scan chain
jtag newtap $CHIPNAME $core -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $CPUTAPID
target create $CHIPNAME.$core arm946e -chain-position $CHIPNAME.$core
-endian little \
-work-area-size 0x1000 -work-area-phys 0x7E000 -work-area-backup 1
$CHIPNAME.$core arm7_9 dbgrq disable
$CHIPNAME.$core arm7_9 dcc_downloads enable
$CHIPNAME.$core arm7_9 fast_memory_access enable
}
After that I've checked the config, and noticed, that dbgrq for 'dsp'
target still enabled:
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* np10.cpu arm946e little np10.cpu running
1 np10.dsp arm946e little np10.dsp running
> np10.cpu arm7_9 dbgrq
use of EmbeddedICE dbgrq instead of breakpoint for target halt disabled
> np10.dsp arm7_9 dbgrq
use of EmbeddedICE dbgrq instead of breakpoint for target halt disabled
> targets np10.cpu
> arm7_9 dbgrq
use of EmbeddedICE dbgrq instead of breakpoint for target halt disabled
> targets np10.dsp
> arm7_9 dbgrq
use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
>
I've added target name display to the command handlers ((maybe, useful
upstream?):)
(attached: target-names.patch)
The result was:
np10.cpu: use of EmbeddedICE dbgrq instead of breakpoint for target
halt disabled
np10.cpu: dcc downloads are enabled
np10.cpu: fast memory access is enabled
np10.cpu: use of EmbeddedICE dbgrq instead of breakpoint for target
halt disabled
np10.cpu: dcc downloads are enabled
np10.cpu: fast memory access is enabled
Oops, The last 3 lines should be started with
np10.dsp
I've traced the program until file: command.c
static int command_unknown(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
{
...
struct command_context *cmd_ctx = current_command_context(interp);
...
}
I have no idea, why the command falls to the 'unknown' handler,
and I have not find any actions to set right command context there.
Attached config script np12.cfg
Logfiles attached: for 2 debug options:
/arm/Olimex/openocd/src/openocd -f np12.cfg -d0 -l oocd-d0.log
/arm/Olimex/openocd/src/openocd -f np12.cfg -d3 -l oocd-d3.log
Build OS: Linux Fedora-17 (x86_64)
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
[hsp:openocd]$ ./config.status --config
'--prefix' '/opt/arm/openocd-0.6' '--enable-maintainer-mode'
'--enable-jlink' '--enable-stlink' '--with-gnu-ld'
'--enable-remote-bitbang' '--enable-dummy' '--enable-ioutil'
'--disable-werror' '--enable-swd' '--enable-arm-jtag-ew'
'--enable-ft2232_libftdi' 'CFLAGS=-m32 -O0 -g'
I will be glad to provide any further support in debugging/testing this issue
and solutions.
Best regards,
Alexander.
-----------------
UPD:
I've checked additional commands:
np10.cpu mdw 0x0 0x4
np10.dsp mdw 0x0 0x4
works as expected for both targets
np10.dsp arm reg
np10.dsp arm disassemble 0 4
operates on *current* target, but not one specified in the command itself.
So it looks like the problem is in the "second-level" command processing.
Regards,
Alex.
np12.cfg
Description: Binary data
oocd-d0.log
Description: Binary data
oocd-d3.log
Description: Binary data
target-names.patch
Description: Binary data
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
