Hi,
> 1. could you post your .cfg script. I'd like tos ee s2c2450 added to
> the target library.
here is the configuration script - same as s3c2440, but with correct ID and
variant:
--------------------------------------------------------------------------------
# Target configuration for the Samsung 2450 system on chip
# Processor : ARM926ejs (wb) rev 0 (v4l)
# Info: JTAG tap: s3c2450.cpu tap/device found: 0x07926F0F
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME s3c2450
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# this defaults to a bigendian
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x07926f0f
}
#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0xE -irmask 0x0f -expected-id
$_CPUTAPID
set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm926ejs
reset_config trst_and_srst
--------------------------------------------------------------------------------
The chip has two internal taps, but they are selected by hardware. That means
the physical BS chain (3) is not accessible in normal operation. AFAIK -
because I'm still waiting conformation form Samsung.
> 2. try adding "reset_config trst_and_srst srst_pulls_trst"
I've tried many reset configuration, including the one you suggest, without
relevant results - as per the reset halt issue. However, I can confirm that
using the setting above does prevent errors on reset command - provided the
jtag frequency is set to 1 (the target seems to be very sensitive to jtag
frequency...). This somehow puzzles me even more, since the target exposes both
resets with no interconnection.
Going back to the reset halt issue, I will investigate further. The ARM
documentation states
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0205a/index.html):
"If you are planning on debugging from reset because you have no code in
memory, you should assert EDBGRQ, or the DBGRQ bit in the EmbeddedICE-RT debug
control register before the ARM core comes out of reset. The ARM core will
enter Halt mode debug before trying to execute anything after coming out of
reset, but only after the ARM core has attempted to fetch a few instructions.
Therefore the memory system should not hold the ARM core off, or return error
responses during these initial instruction fetches."
I've tried to tweak with arm7_9_assert_reset in order to match the suggested
sequence - instead of using vector catch or watchpoints. Unfortunately, I'm not
enough inside the project to cope with the possible side effects - but anyway,
this approach did not work. I will chack further, since the reset halt
functionality is of major interest when bringing the target to life.
Best regards,
Stefano
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
