[Openocd-development] STM32 "reset halt" appears broken

[Øyvind Harboe]

"reset halt" for STM32 appears to be broken in SVN HEAD...

I don't know if this is a regression.

"reset run", "halt", "flash probe 0" works.
"reset halt", "flash probe 0" fails.

Any ideas?

Log attached....


Open On-Chip Debugger

debug_level 3
reset halt

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0x
ba00, Version: 0x3)
JTAG Tap/device matched
JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x64
10, Version: 0x1)
JTAG Tap/device matched
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1170)
timed out while waiting for target halted
Runtime error, file "embedded:startup.tcl", line 211:
expected return code but got 'TARGET: stm32.cpu - Not halted'
in procedure 'ocd_process_reset'

flash probe 0

Target not halted
unknown error when probing flash bank '#0' at 0x00000000

reset run

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0x
ba00, Version: 0x3)
JTAG Tap/device matched
JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x64
10, Version: 0x1)
JTAG Tap/device matched
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4

halt

target state: halted
target halted due to debug-request, current mode: Handler SysTick
xPSR: 0x6100000f pc: 0x08000144

flash probe 0

device id = 0x20016410
flash size = 128kbytes
flash 'stm32x' found at 0x08000000

[Spencer Oliver]

Post by Øyvind Harboe
"reset halt" for STM32 appears to be broken in SVN HEAD...
I don't know if this is a regression.
"reset run", "halt", "flash probe 0" works.
"reset halt", "flash probe 0" fails.
Any ideas?

Not aware of any issues - i can check tomorrow.

Cheers
Spen

[Magnus Lundin]

Hi

jtag_khz ??
do you have code in flash that configures the pll ?

When I test, I get exactly the same behaviour when khz>=2000 (FT2232 )
. But it works well for slower speeds.
Once the onboard clock config code has configured the pll (72khz) then I
can use 6000khz without problems.

There are some weirdness in the whole rest sequence with resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just noticed the dual rsets
and used the onboard reset button, works great all the time :) .

Regards,
Magnus

Post by Øyvind Harboe
"reset halt" for STM32 appears to be broken in SVN HEAD...
I don't know if this is a regression.
"reset run", "halt", "flash probe 0" works.
"reset halt", "flash probe 0" fails.
Any ideas?
Log attached....
Open On-Chip Debugger

debug_level 3
reset halt

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0x
ba00, Version: 0x3)
JTAG Tap/device matched
JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x64
10, Version: 0x1)
JTAG Tap/device matched
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4
BUG: keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1170)
timed out while waiting for target halted
expected return code but got 'TARGET: stm32.cpu - Not halted'
in procedure 'ocd_process_reset'

flash probe 0

Target not halted
unknown error when probing flash bank '#0' at 0x00000000

reset run

JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0x
ba00, Version: 0x3)
JTAG Tap/device matched
JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x64
10, Version: 0x1)
JTAG Tap/device matched
AHBAP: dp_select 0x10, ap_csw 0xa2000002, ap_tar 0xe000edf0
SWJ-DP OVERRUN - check clock or reduce jtag speed
dcb_dhcsr 0x1010001, nvic_shcsr 0x0, nvic_cfsr 0x0, nvic_bfar 0x200007f4

halt

target state: halted
target halted due to debug-request, current mode: Handler SysTick
xPSR: 0x6100000f pc: 0x08000144

flash probe 0

device id = 0x20016410
flash size = 128kbytes
flash 'stm32x' found at 0x08000000
------------------------------------------------------------------------
This body part will be downloaded on demand.

[Øyvind Harboe]

What config script and target board are you using?

[Magnus Lundin]

Post by Øyvind Harboe
What config script and target board are you using?

I have played a little with the standard scrips but the interface is
basic ft2232 usbjtag layout and nonstandard vid/pid and Serialnumber string.

For the target it is the stm32.cfg but the reset config is:

jtag_nsrst_delay 100
jtag_ntrst_delay 100

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

[Øyvind Harboe]

Post by Magnus Lundin
resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just noticed the dual rsets
and used the onboard reset button, works great all the time :) .

Perhaps the target script or cortex should override the default
ocd_process_reset script.... i.e. by default resetting the entire
chain was considered a clever idea, but for cortex, it might not
be such a great thing...

[Magnus Lundin]

Post by Øyvind Harboe

Post by Magnus Lundin
resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just noticed the dual rsets
and used the onboard reset button, works great all the time :) .

Perhaps the target script or cortex should override the default
ocd_process_reset script.... i.e. by default resetting the entire
chain was considered a clever idea, but for cortex, it might not
be such a great thing...

I dont think it is a Cortex issue, but as I understand it every reset
does the following

first calls jtag_reset_init,
generating a sequence of trst/srst on the jtag interface
and then revalidating the scanchain, a VERY good idea.

But then the target reset code is called, sending the same, almost,
sequence of trst/srst
and not revalidating the scanchain.

Am I missing something ?

Regards,
Magnus

[Øyvind Harboe]

Post by Øyvind Harboe

Post by Magnus Lundin
resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just noticed the dual rsets
and used the onboard reset button, works great all the time :) .

Perhaps the target script or cortex should override the default
ocd_process_reset script.... i.e. by default resetting the entire
chain was considered a clever idea, but for cortex, it might not
be such a great thing...

I dont think it is a Cortex issue, but as I understand it every reset does
the following
first calls  jtag_reset_init,
generating  a sequence of trst/srst on the jtag interface
and then revalidating the scanchain, a VERY good idea.
But then the target reset code is called,  sending the same, almost,
sequence of trst/srst
and not revalidating the scanchain.
Am I missing something ?

That's about it.

But all this can be configured in the target configuration scripts.

What *should* be done for Cortex-M3 then?

Regards,
Magnus

[Michel Catudal]

Post by Øyvind Harboe

Post by Magnus Lundin
resetting first
the jtag, and this rsets my target also, and then a little later
resetting the Cortex core giving two rests in quick succeion. It works
but I dont like it. For my old LM2S811 reset does not work well, but I
have not had time to really dig in to this, just noticed the dual rsets
and used the onboard reset button, works great all the time :) .

Perhaps the target script or cortex should override the default
ocd_process_reset script.... i.e. by default resetting the entire
chain was considered a clever idea, but for cortex, it might not
be such a great thing...

It depends. WIth IAR If I don't reset the device correctly it programs
garbage. What I found out was that the DMA was still running
and wiping out some RAM location used by the downloader. With IAR you
have the option to reset or not reset the peripherals.
Perhaps those kind of options should be available with OpenOCD.

Michel

[Øyvind Harboe]

Post by Michel Catudal
It depends. WIth IAR If I don't reset the device correctly it programs
garbage. What I found out was that the DMA was still running
and wiping out some RAM location used by the downloader. With IAR you
have the option to reset or not reset the peripherals.
Perhaps those kind of options should be available with OpenOCD.

This sounds strange. So the normal powercycle reset is not available
throught srst/trst?

How are peripherals reset then, in an init script?

[Michel Catudal]

Post by Øyvind Harboe

Post by Michel Catudal
It depends. WIth IAR If I don't reset the device correctly it programs
garbage. What I found out was that the DMA was still running
and wiping out some RAM location used by the downloader. With IAR you
have the option to reset or not reset the peripherals.
Perhaps those kind of options should be available with OpenOCD.

This sounds strange. So the normal powercycle reset is not available
throught srst/trst?
How are peripherals reset then, in an init script?

I don't have IAR here. I will check monday. My options for reset are
"normal" and "reset all peripherals" If I can't see what it runs I will
ask my contact at IAR. At the price I pay I should be able to get a
clear answer. I spent several days trying to figure out why it was not
programming correctly.

I only found the problem in code where I use DMA. I haven't tested
OpenOCD with IAR, I use the yellow device from Segger and the IAR driver.

Michel

[Spencer Oliver]

Post by Magnus Lundin

Post by Øyvind Harboe
What config script and target board are you using?

I have played a little with the standard scrips but the
interface is basic ft2232 usbjtag layout and nonstandard
vid/pid and Serialnumber string.
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#use combined on interfaces or targets that can't set
TRST/SRST separately reset_config trst_and_srst #reset_config
srst_only srst_pulls_trst

This statement should only be true for early luminary - we get around that
by using the -variant lm3s
Then the luminary id is checked to see if it is effected.

stm32 does not suffer any reset issues as far as i am aware - asserting srst
will not effect the core debug registers.
asserting trst does not effect core debug registers either.

Cheers
Spen

[Spencer Oliver]

Post by Michel Catudal

Post by Michel Catudal
It depends. WIth IAR If I don't reset the device correctly

it programs

Post by Michel Catudal
garbage. What I found out was that the DMA was still running and
wiping out some RAM location used by the downloader. With

IAR you have

Post by Michel Catudal
the option to reset or not reset the peripherals.
Perhaps those kind of options should be available with OpenOCD.

This sounds strange. So the normal powercycle reset is not
available throught srst/trst?

asserting srst will reset the peripherals, however most tools (IAR, Keil) by
default use a software reset.

Cheers
Spen