Problem with str736 (always running)

Development Boards MicroMod
1

I have an STR736FV2 and I use openocd re100 witch signalizer.

The configurazione script I use is:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Signalyzer A"
ft2232_layout signalyzer
ft2232_vid_pid 0x0403 0xbca0
jtag_speed 0

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset

#target <type> <startup mode>
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
target arm7tdmi little run_and_halt 0 arm7tdmi
run_and_halt_time 0 30

working_area 0 0xA0003000 0x1000 nobackup

#flash bank <driver> <base> <size> <chip_width> <bus_width>
flash bank str7x 0x80000000 0x00010000 0 0 STR73x 0

Openocd seems to connect to target, but the core is always running. If I call wait_halt I obtain

Error: target.c:1242 handle_wait_halt_command(): timed out while waiting for target halt

I tried changing jtag_speed to some values from 0 to 180 with no success.

The board is quite new so never programmed before. Do I need to follow a special procedure to program flash for the first time?

Is configurazione script correct?

thanks

2

Hi,

please run the OpenOCD with “-d -l ” and send me the resulting log (Dominic.Rath gmx.de).

Regards,

Dominic

3

Thanks for sending the log.

The “wait_halt” command isn’t meant to be used to halt the target - that’s what “halt” is for. “wait_halt” is mainly for use in scripts, to make sure that successive commands work with a halted target.

What puzzles me is that the target didn’t enter halt mode after startup. You’ve specified “target … run_and_halt” and “run_and_halt_time 0 30”, so the target should enter debug mode after running for about 30ms.

Try adding “jtag_ntrst_delay 500” and “jtag_nsrst_delay 500” - these two settings account for delays because of on-board reset circuitry when deasserting the reset lines.

Regards,

Dominic

4

Dominic:
Try adding “jtag_ntrst_delay 500” and “jtag_nsrst_delay 500” - these two settings account for delays because of on-board reset circuitry when deasserting the reset lines.

I tried with no result. Now I call halt, but it remains in running state.

Other idea?

thanks

5

Try changing “run_and_halt” in the target line to “reset_run”, then on the telnet interface use:

arm7_9 dbgrq enable

halt

and send me the resulting log again.

Regards,

Dominic

6

It could be an hardware problem…

I want to verify this hypothesis before doing other test…

thanks

7

I have similar symptoms on my AT91SAM7S - it can’t understand “reset_halt” . But … it was reacting on “halt” via telnet… now - i switched from slow clock to main clock and even halt doesn’t wok.

So I just wait for a loooooong time (clock switching procedure is in sram) and restarts … so it ‘halts’ again