Hi Drasko,
your system has an ARM946E. Should have "vector_catch" capability.
Please check if command "arm9 vector_catch" shows the reset feature.
In such case, after set it to catch reset, you can press the reset
button to trigger OpenOCD and get CPU halted at first instruction.

If everything works, then you can have a look at the file
tcl/chip/st/spear/quirk_no_srst.tcl
The file above is not specific for ST SPEAr, but today is tested and
used on such system only.
It uses vector_catch and integrates in OpenOCD reset command the
required functionality to catch the reset.
You could use similar stuff for your system too.

Just an additional bit... this have to be run from telnet interface.
Never tested from gdb

Best Regards,
Antonio Borneo

On Sat, Dec 11, 2010 at 3:03 AM, Drasko DRASKOVIC
<drasko.drasko...@gmail.com> wrote:
> Hi all,
> I have run into one interesting issue, so I was hoping that somebody
> could help me understand the problem.
>
> My SoC has JTAG with no SRST (just TRST), and system reset can be done
> in two ways :
> 1) mechanically, by pressing the reset button
> 2) writing one byte to dedicated SOC_RESET register
>
> However,
> when I try to write into this register, I get errors :
>
> Debug: 329 17328 target.c:1320 target_write_buffer(): writing buffer
> of 1 byte at 0x20004104
> Debug: 330 17328 arm946e.c:519 arm946e_write_memory(): -
> Debug: 331 17337 embeddedice.c:502 embeddedice_write_reg(): 0: 0x00000004
> Debug: 332 17337 embeddedice.c:502 embeddedice_write_reg(): 0: 0x00000005
> Warn : 333 17339 core.c:783 jtag_check_value_inner(): Bad value
> '00000004' captured during DR or IR scan:
> Warn : 334 17339 core.c:784 jtag_check_value_inner():  check_value: 0x00000009
> Warn : 335 17339 core.c:793 jtag_check_value_inner():  check_mask: 0x00000009
> Error: 336 17339 arm7_9_common.c:2639 arm7_9_write_memory(): JTAG
> error while reading cpsr
> Debug: 337 17339 command.c:647 run_command(): Command failed with
> error code -307
> User : 338 17339 command.c:688 command_run_line(): Command handler
> execution failed
> in procedure 'mwb'
>
>
> I noticed that CPU starts running immediately, creating these errors.
> I can see this by polling :
>> poll
> background polling: on
> TAP: d1.cpu (enabled)
> target state: running
>
> QUESTION :  why does OpenOCD hold it in HALT mode anymore ?
>
> Similarly, when I am in the halt mode, and I do mechanical reset, CPU
> will start running, booting the bootloader. OpenOCD does not hold it
> in HALT anymore.
>
> How to prevent this behavior and be capable to safely reset the SoC ?
>
> Best regards,
> Drasko
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to