Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell davi...@pacbell.net wrote: Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Not all SoCs reset peripherals like that; don't assume they do. Likewise, not all boards. - Dave It's not an assumption, it's in the manual. Do you have an example of a microcontroller which doesn't reset the bulk of the peripherals on a NRST or equivalent? This is somewhat of a regression, since in 0.4.0, the STM32 (and likely other cortex-m3) peripherals were being reset when a (soft or hard) reset was issued from OpenOCD. Now they're suddenly not when the default configs are used. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Hi!
This patch changes the default behaviour of Cortex-M3 soft-reset. More
details can be found in thread STM32 reset_config.
I've tested that with STM32 - everything works fine, peripherals are
reset as they should be (with standard cfg files).
4\/3!!
From c8303d849cea9a2ebf0f2e36f1bec8f057b5ad85 Mon Sep 17 00:00:00 2001
From: Freddie Chopin freddie_cho...@op.pl
Date: Thu, 11 Nov 2010 11:55:29 +0100
Subject: [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3
soft-reset.
Cortex-M3 can be reset externally - via SRST pin - or internally - through
SYSRESETREQ or VECTRESET. VECTRESET does not reset on-chip peripherals,
SYSRESETREQ resets them and (optionally) forces external reset pin to
active state, resetting other devices connected to this signal on board.
Some broken Cortex-M3 implementations (like some Sterllaris chips) do not
fully support SYSRESETREQ, but that is (and should be) handled in target
cfg files.
If no SRST pin is available, Cortex-M3 soft-reset is required, so use
SYSRESETREQ by default. User can force VECTRESET in target cfg file with
cortex_m3 reset_config vectreset.
Signed-off-by: Freddie Chopin freddie_cho...@op.pl
---
doc/openocd.texi |7 +--
src/target/cortex_m3.c | 15 ---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index f946bdf..a1910d6 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -6620,12 +6620,15 @@ This finishes by listing the current vector catch
configuration.
@deffn Command {cortex_m3 reset_config}
(@option{srst}|@option{sysresetreq}|@option{vectreset})
Control reset handling. The default @option{srst} is to use srst if fitted,
-otherwise fallback to @option{vectreset}.
+otherwise fallback to @option{sysresetreq}.
@itemize @minus
-...@item @option{srst} use hardware srst if fitted otherwise fallback to
@option{vectreset}.
+...@item @option{srst} use hardware srst if fitted otherwise fallback to
@option{sysresetreq}.
@item @option{sysresetreq} use NVIC SYSRESETREQ to reset system.
@item @option{vectreset} use NVIC VECTRESET to reset system.
@end itemize
+Using @option{sysresetreq} is equivalent to real reset, as it also resets
all on-chip peripherals
+and (optionally) forces external reset pin to active state, resetting other
devices connected to this signal on
+board. Some broken Cortex-M3 implementations (like some Sterllaris chips) do
not fully support this option.
Using @option{vectreset} is a safe option for all current Cortex-M3 cores.
This however has the disadvantage of only resetting the core, all peripherals
are uneffected. A solution would be to use a @code{reset-init} event handler
to manually reset
diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
index f2947ad..e2e9c3f 100644
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -934,7 +934,7 @@ static int cortex_m3_assert_reset(struct target *target)
*/
if (!(jtag_reset_config RESET_HAS_SRST)
(cortex_m3-soft_reset_config == CORTEX_M3_RESET_SRST))
{
- reset_config = CORTEX_M3_RESET_VECTRESET;
+ reset_config = CORTEX_M3_RESET_SYSRESETREQ;
}
/* Enable debug requests */
@@ -999,13 +999,14 @@ static int cortex_m3_assert_reset(struct target *target)
else
{
/* Use a standard Cortex-M3 software reset mechanism.
-* We default to using VECRESET as it is supported on all
current cores.
-* This has the disadvantage of not resetting the peripherals,
so a
-* reset-init event handler is needed to perform any peripheral
resets.
+* We default to using SYSRESETREQ as it should be supported on
all Cortex-M3 cores.
+* This has the advantage of resetting the peripherals, so it
is equivalent to a
+* real reset. In case of broken Cotex-M3 implementations
(like some Stellaris
+* chips), override this in cfg files with cortex_m3
reset_config vectreset.
*/
retval = mem_ap_write_atomic_u32(swjdp, NVIC_AIRCR,
- AIRCR_VECTKEY | ((reset_config ==
CORTEX_M3_RESET_SYSRESETREQ)
- ? AIRCR_SYSRESETREQ : AIRCR_VECTRESET));
+ AIRCR_VECTKEY | ((reset_config ==
CORTEX_M3_RESET_VECTRESET)
+ ? AIRCR_VECTRESET : AIRCR_SYSRESETREQ));
if (retval != ERROR_OK)
return retval;
@@ -1944,7 +1945,7 @@ static int cortex_m3_init_arch_info(struct target *target,
cortex_m3-jtag_info.scann_size = 4;
/* default reset mode is to use srst if fitted
-* if not it will use CORTEX_M3_RESET_VECTRESET */
+* if not it will use CORTEX_M3_RESET_SYSRESETREQ*/
cortex_m3-soft_reset_config = CORTEX_M3_RESET_SRST;
armv7m-arm.dap = armv7m-dap;
[Openocd-development] S3C6410 resume address timeout sometime, so I can't halt and resume an program.
HI, I want to debug u-boot for s3c6410 with openocd 0.4.0, but I fount that the resume command timeout some time. So I use a simple program to test, it runs on the internal sram . I use openocd to download init.bin to the internal sram , and use the resume command to run it. The steps are: 1. load_image init/init.bin 0x0c00 2. resume 0x0c00 3. halt 4. resume 0x0c00// when resume 0x0c00, it is alway ok. 5. halt repeat step 4 and step 5, it is OK. 6. resume 0x0c40// when resume 0x0c40, 0x0c90 ..., it will be timeout sometime 7. halt repeat step 6 and step 7, it will be timeout sometime at step 6, but I can halt it again and repeat my test. The init.S is simble, the code is: .text .global _start _start: Reset: mrs r0, CPSR bic r0, r0, #0x1f orr r0, r0, #0xd3 msr CPSR_fc, r0 @ Supervisor mode, sets the I and F bits cpu_init_crit: /* * flush v4 I/D caches */ mov r0, #0 mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */ mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */ /* * disable MMU stuff and caches */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x2300 @ clear bits 13, 9:8 (--V- --RS) bic r0, r0, #0x0087 @ clear bits 7, 2:0 (B--- -CAM) orr r0, r0, #0x0002 @ set bit 2 (A) Align orr r0, r0, #0x1000 @ set bit 12 (I) I-Cache mcr p15, 0, r0, c1, c0, 0 /* Peri port setup */ ldr r0, =0x7000 orr r0, r0, #0x13 mcr p15,0,r0,c15,c2,4 @ 256M(0x7000-0x7fff) lowlevel_init:// this is the 0x40 offset ldr r0, =ELFIN_GPIO_BASE ldr r1, =0x str r1, [r0, #MEM1DRVCON_OFFSET] .. halt: b halt ds...@ustc.edu 2010-11-11 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] S3C6410 resume address timeout sometime, so I can't halt and resume an program.
The log is: load_image init/init.bin 0x0c00 776 bytes written at address 0x0c00 downloaded 776 bytes in 0.046875s (16.167 kb/s) resume 0x0c00 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c00 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c00 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c00 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c40 Timeout (1000ms) waiting for instructions to complete Command handler execution failed in procedure 'resume' called at file command.c, line 650 called at file command.c, line 361 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c40 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 resume 0x0c40 halt target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x21d3 pc: 0x0cd8 HI, I want to debug u-boot for s3c6410 with openocd 0.4.0, but I fount that the resume command timeout some time. So I use a simple program to test, it runs on the internal sram . I use openocd to download init.bin to the internal sram , and use the resume command to run it. The steps are: 1. load_image init/init.bin 0x0c00 2. resume 0x0c00 3. halt 4. resume 0x0c00// when resume 0x0c00, it is alway ok. 5. halt repeat step 4 and step 5, it is OK. 6. resume 0x0c40// when resume 0x0c40, 0x0c90 ..., it will be timeout sometime 7. halt repeat step 6 and step 7, it will be timeout sometime at step 6, but I can halt it again and repeat my test. The init.S is simble, the code is: .text .global _start _start: Reset: mrs r0, CPSR bic r0, r0, #0x1f orr r0, r0, #0xd3 msr CPSR_fc, r0 @ Supervisor mode, sets the I and F bits cpu_init_crit: /* * flush v4 I/D caches */ mov r0, #0 mcr p15, 0, r0, c7, c7, 0 /* flush v3/v4 cache */ mcr p15, 0, r0, c8, c7, 0 /* flush v4 TLB */ /* * disable MMU stuff and caches */ mrc p15, 0, r0, c1, c0, 0 bic r0, r0, #0x2300 @ clear bits 13, 9:8 (--V- --RS) bic r0, r0, #0x0087 @ clear bits 7, 2:0 (B--- -CAM) orr r0, r0, #0x0002 @ set bit 2 (A) Align orr r0, r0, #0x1000 @ set bit 12 (I) I-Cache mcr p15, 0, r0, c1, c0, 0 /* Peri port setup */ ldr r0, =0x7000 orr r0, r0, #0x13 mcr p15,0,r0,c15,c2,4 @ 256M(0x7000-0x7fff) lowlevel_init:// this is the 0x40 offset ldr r0, =ELFIN_GPIO_BASE ldr r1, =0x str r1, [r0, #MEM1DRVCON_OFFSET] .. halt: b halt ds...@ustc.edu 2010-11-11 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ds...@ustc.edu 2010-11-11 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] S3C6410 resume address timeout sometime, so I can't halt and resume an program.
Please try the master branch. 0.4.0 is a bit old for reporting bugs to the list. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] segfault when gdb connects, but target is not connected
On Thu, Nov 11, 2010 at 08:48, Øyvind Harboe oyvind.har...@zylin.com wrote: Try: openocd -c interface dummy -c gdb_memory_map disable -f target/stm32.cfg No segfault in this case. -- Domen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
--- On Thu, 11/11/10, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: It's not an assumption, it's in the manual. Do you have an example of a microcontroller which doesn't reset the bulk of the peripherals on a NRST or equivalent? Not handy, no; it surprised me too. ISTR there was a register controlling this behavior, and it seemed to be part of debug support. On the other hand, some non-microcontroller SoCs I've used take a different approach and have a formal controller dedicated to reset handling, which doesn't hook up to NSRST but offers per-peripheral controls over reset sequencing. On those SoCs, NSRST isn't a very widely used signal; affects only CPU cores. Debuggers and boot code are expected to talk to the reset controller as needed during bringup. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: If no SRST pin is available, Cortex-M3 soft-reset is required, How common is this case? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] How 2 build with new Jim???
After bootstrap and configure (per instructions), I get build failures on Linux with an all but pure clone of mainline. (Quilt and git report only a patch to the git ignore file, not to any code.) Same config I've used on this machine most of the last year. make all-recursive make[1]: Entering directory `/home/db/kernel/oocd' Making all in src make[2]: Entering directory `/home/db/kernel/oocd/src' make all-recursive make[3]: Entering directory `/home/db/kernel/oocd/src' Making all in jtag make[4]: Entering directory `/home/db/kernel/oocd/src/jtag' make all-recursive make[5]: Entering directory `/home/db/kernel/oocd/src/jtag' Making all in drivers make[6]: Entering directory `/home/db/kernel/oocd/src/jtag/drivers' /bin/bash ../../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c -o driver.lo driver.c /bin/bash ../../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT bitbang.lo -MD -MP -MF .deps/bitbang.Tpo -c -o bitbang.lo bitbang.c /bin/bash ../../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c -o dummy.lo dummy.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c driver.c -o driver.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT bitbang.lo -MD -MP -MF .deps/bitbang.Tpo -c bitbang.c -o bitbang.o libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.c -o dummy.o In file included from ../../../src/helper/log.h:29, from ../../../src/jtag/jtag.h:27, from driver.c:34: ../../../src/helper/command.h:34:17: error: jim.h: No such file or directory ../../../src/helper/command.h:35:21: error: jim-nvp.h: No such file or directory In file included from ../../../src/helper/log.h:29, from ../../../src/jtag/jtag.h:27, from driver.c:34: ../../../src/helper/command.h:61: error: expected specifier-qualifier-list before ‘Jim_Interp’ ../../../src/helper/command.h:182: error: expected specifier-qualifier-list before ‘Jim_CmdProc’ ../../../src/helper/command.h:218: error: expected specifier-qualifier-list before ‘Jim_CmdProc’ ../../../src/helper/command.h:316: error: expected ‘)’ before ‘*’ token ../../../src/helper/command.h:322: error: expected declaration specifiers or ‘...’ before ‘Jim_Interp’ ../../../src/helper/command.h:427: error: expected ‘)’ before ‘*’ token In file included from driver.c:34: ../../../src/jtag/jtag.h:175: error: expected ‘)’ before ‘*’ token ../../../src/jtag/jtag.h:215: error: expected specifier-qualifier-list before ‘Jim_Interp’ In file included from driver.c:34: ../../../src/jtag/jtag.h:698: error: expected ‘)’ before ‘*’ token make[6]: *** [driver.lo] Error 1 make[6]: *** Waiting for unfinished jobs In file included from ../../../src/helper/log.h:29, from ../../../src/jtag/jtag.h:27, from ../../../src/jtag/interface.h:29, from dummy.c:24: ../../../src/helper/command.h:34:17: error: jim.h: No such file or directory ../../../src/helper/command.h:35:21: error: jim-nvp.h: No such file or directory In file included from ../../../src/helper/log.h:29, from ../../../src/jtag/jtag.h:27, from ../../../src/jtag/interface.h:29, from dummy.c:24: ../../../src/helper/command.h:61: error: expected specifier-qualifier-list before ‘Jim_Interp’ ../../../src/helper/command.h:182: error: expected specifier-qualifier-list before ‘Jim_CmdProc’ ../../../src/helper/command.h:218: error: expected specifier-qualifier-list before ‘Jim_CmdProc’ ../../../src/helper/command.h:316: error: expected ‘)’ before ‘*’ token ../../../src/helper/command.h:322:
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-11 17:51, Peter Stuge wrote: Freddie Chopin wrote: If no SRST pin is available, Cortex-M3 soft-reset is required, How common is this case? How common is what? Lack of SRST? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? Instead of VECTRESET, which does not reset peripherals. If SRST is available, no soft-reset is required. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
What output do you get when running bootstrap? It should print the instructions on how to build and install jim tcl. Did you try running the current master branch? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
--- On Thu, 11/11/10, Øyvind Harboe oyvind.har...@zylin.com wrote: What output do you get when running bootstrap? This time I noticed some stuff ... but that seems wrong. Bootstrap should bootstrap, not leave the job incomplete and in need of repairs. It should print the instructions on how to build and install jim tcl. No, it should get to the point where a top-level configure and make will work without errors. Builds are now needlessly error-prone and painful. And don't match the docs either. I still get errors even if I build jim first. I'm goind to have to waste time finding sources of these needless build errors. Did you try running the current master branch? That's what I said I did: current mainline clone. -- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: If no SRST pin is available, Cortex-M3 soft-reset is required, How common is this case? How common is what? Lack of SRST? Yes? so use SYSRESETREQ by default. Default instead of SRST, or default instead of VECTRESET? Instead of VECTRESET, Ok. If SRST is available, no soft-reset is required. Of course. What decides on the code path? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
On Thu, Nov 11, 2010 at 6:52 PM, David Brownell davi...@pacbell.net wrote: --- On Thu, 11/11/10, Øyvind Harboe oyvind.har...@zylin.com wrote: What output do you get when running bootstrap? This time I noticed some stuff ... but that seems wrong. Bootstrap should bootstrap, not leave the job incomplete and in need of repairs. In the list there has been discussions on how to improve the build procedure. By default OpenOCD should build the Jim Tcl submodule automatically, but there should be an option to use the installed Jim Tcl. We have both capabilities, the master branch uses the installed Jim Tcl, and a patch hardcodes building Jim Tcl. Now we just need the two at the same time, which requires a bit of configure knowledge. So there is a consensus on what the behavior should be, we're just a patch short. I don't think bootstrap should print out instructions, but it seemed the best thing in lieu of the remaining patches. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 11/11/2010 05:01, Peter Stuge wrote: Spencer Oliver wrote: The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. Please give more detail about those nxp parts? All LPC17xx devices according to docs: This is intended to force a large system reset of all major components except for debug. Note: support for SYSRESETREQ is not included in LPC17xx devices. http://www.nxp.com/documents/user_manual/UM10360.pdf page 769 This is why VECTRESET was chosen as the safe default on all cortexm3 cores. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 11/11/2010 11:00, Freddie Chopin wrote: Hi! This patch changes the default behaviour of Cortex-M3 soft-reset. More details can be found in thread STM32 reset_config. I've tested that with STM32 - everything works fine, peripherals are reset as they should be (with standard cfg files). 4\/3!! I disagree with this patch as SYSTEMRESET is not supported as expected on all cores. As explained before LPC17xx do not support it. Some variants of the lm3 core will fail, the same goes for some stm32 devices i have tested. I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-11 19:34, Peter Stuge wrote: Freddie Chopin wrote: If no SRST pin is available, Cortex-M3 soft-reset is required, How common is this case? How common is what? Lack of SRST? Yes? For me such situations are almost impossible, but some strange and bizarre policy makes default target file for stm32 tell OpenOCD there is no reset at all... Of course user can change that, but with this assumption, target, board and interface cfg files can as well be deleted, as the user can write his/her own... Number of things that users of OpenOCD have to do prior to using it for it's main purpose tends to grow, rather than shrink... I (and many other people) like to use OpenOCD with just command-line parameters, like this: openocd -f interface/... -f target/... It worked fine, and that was very cool, because one does not need to prepare millions of config files for each project / occasion. Now with this method peripherals are NOT reset during reset ... command on stm32... I know what to do to fix this, but I bet 95% of OpenOCD users don't. You can decide that it's their problem if you want. The files in target directory are soon going to be useless alone. Completely off-topic: sometimes I think, that open-source projects are just a cover-up made by people working for big companies - they ensure that the software works, but is impossible to use without reading the manual twice, browsing through the mail archives, searching the web for half a day and then reading the manual again... Then they find out that this problem they have is a policy and that it will never be changed, because someone decided that it's the right way to go. If SRST is available, no soft-reset is required. Of course. What decides on the code path? I don't understand the question, so here is a blind answer... 1. no chip resets, no cortex-m3 reset method specified - use SYSRESETREQ (now use VECTRESET - does not reset peripherals) 2. chip reset available, cortex-m3 reset method specified - use cortex-m3 reset method that was specified 3. chip resets available, no cortex-m3 reset method specified - use SRST 4. no chip resets, cortex-m3 reset method specified - use it, but if cortex-m3 reset method is SRST that will be changed to SYSRESETREQ (now it will be changed to VECTRESET, note as in 1.) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-11 20:47, Spencer Oliver wrote: I disagree with this patch as SYSTEMRESET is not supported as expected on all cores. Shouldn't the code assume that this standard mechanism works as the standard says? If some chip does not support it, than this chip should have VECTRESET selected in its config file, why make trouble for chips that obey this standard? As explained before LPC17xx do not support it. So lpc17xx.cfg file should force VECTRESET. Some variants of the lm3 core will fail That's why stellaris.cfg forces VECTRESET for them. the same goes for some stm32 devices i have tested. All STM32 that I had in hand support SYSRESETREQ without any problems, so why should STM32 users be forced to edit cfg files? I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. LPC2xxx supposedly cannot be reset into halted mode (because SRST pulls TRST) - should ARM7 control functions assume that as a default? Do they? So why does Cortex-M3 assume that something is broken as a default? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How 2 build with new Jim???
Øyvind Harboe wrote: By default OpenOCD should build the Jim Tcl submodule automatically, but there should be an option to use the installed Jim Tcl. I disagree strongly with this. Moving Jim out into a separate package means that it should also be treated as a separate package. (Which it is, so it makes perfect sense!) I have added dev-lang/jimtcl and dev-embedded/openocd ebuilds to my Gentoo Linux overlay, so you can build the latest openocd from git easily using these commands, if you are running Gentoo: # set up layman emerge layman # and add the source line to /etc/make.conf per instructions layman -a stuge # permit git build of openocd mkdir -p /etc/portage echo 'dev-lang/jimtcl **' /etc/portage/package.keywords echo 'dev-embedded/openocd **' /etc/portage/package.keywords # install openocd from git (it pulls in jimtcl) emerge =openocd- (If you want to upgrade later, just run the last emerge again.) My ebuilds here: http://git.stuge.se/?p=stuge-overlay.git;a=blob;f=dev-lang/jimtcl/jimtcl-.ebuild http://git.stuge.se/?p=stuge-overlay.git;a=blob;f=dev-embedded/openocd/openocd-.ebuild My jimtcl ebuild builds a shared library because I think that makes the most sense. Making the packages I noticed that the build infrastructure for Jim is a little simpler than most other autotools packages, it has a hand-made Makefile rather than an automake-generated one. In particular the make install target doesn't work like others. There are some hard coded paths here and there, which also makes it a bit more difficult in general to install Jim into the system. But this could probably be fixed fairly easily. People can hopefully benefit from the ebuilds as well. Anyway, my point is, install Jim like the independent package it is, and let OpenOCD require Jim as normal, and all is fine. For those who like Cygwin, it is my experience that it might be easy to create a jimtcl package also in Cygwin, which openocd would depend on, and all would be well. We have both capabilities, the master branch uses the installed Jim Tcl, and a patch hardcodes building Jim Tcl. Now we just need the two at the same time, which requires a bit of configure knowledge. Please remember that, as I've pointed out before, an autotools project build is not complete until *after* make install. IMO openocd must not make assumptions about Jim beyond that it should be installed in system directories, or that any required exceptional settings are given to openocd configure, either via environment variables which is very simple, or via a --with-jim-tcl=/wherever option. I think it would be fine to not add such an option, and either just require Jim to be installed in the system, or require the right CFLAGS and LDFLAGS environment variables to openocd configure. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Hi! I've thought about that whole patch which adds cortex-m3 reset_config command and I think it's not very good now (if I correctly understand its behavior). Let's say, that there is a chip which has some problems with SYSRESETREQ, so the target config file forces VECTRESET (which is not a perfect solution, as it does not reset peripherals). Now - according to OpenOCD (brilliant) policy of target config files - there is no reset_config command in this file. As 99% of chips and boards on this planet do have resets wired up properly, user can specify reset_config on his/her own, but what for? The cortex-m3 reset_config command gets priority (that's my understanding...), and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. And again we are back to overriding mysterious configuration options by an inexperienced user who just wants to do some simple debugging on some simple microcontroller... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
Freddie Chopin wrote: How common is what? Lack of SRST? Yes? For me such situations are almost impossible, Impossible? Weird measure of common. :) but some strange and bizarre policy makes default target file for stm32 tell OpenOCD there is no reset at all... My perception of the situation is strongly the opposite. There is no policy, relax, there is just people working together making something generic that works. This is a difficult task. Number of things that users of OpenOCD have to do prior to using it for it's main purpose tends to grow, rather than shrink... Maybe things need to get a little worse before they can get a lot better. I think we're still learning about cm3. Completely off-topic: sometimes I think, that open-source projects are just a cover-up made by people working for big companies Sorry, this is a bit silly. I can understand that open source projects are immensely frustrating if there is some kind of incompatibility, be it attitude or philosophy or even trivial stuff like coding style. And the fact that projects to a high degree are based on voluntary contributions means that it can be basically impossible to get something done the way you like unless you do it yourself. I am not complaining that *you* do not contribute here, I mean this completely generally. I also completely understand that not everyone can do the changes themselves, but it's also important to remember that those who selflessly do want to contribute code changes that will help others have very limited resources, so it might take time. Using the program is also very important, I belive that testing and bug reports is the only way to make significant progress.. And documentation, and training for others, and so on.. Just remember that this is really just piece of sh*t software that we are hacking on to make it do a decent job. It is still good enough to sell products based on, and sometimes it's many many times better than proprietary products, but it is still not that amazing. Very little software is. Fixing that is of course a huge task, but we all want to make things better and try to help as best we can. If SRST is available, no soft-reset is required. Of course. What decides on the code path? I don't understand the question, Sorry, it was unclear. I meant to ask how openocd knows to use SRTS or soft-reset and if soft-reset then how it knows to use SYSRESETREQ or VECTRESET. I guess it's all target and board config files. so here is a blind answer... 1. no chip resets, no cortex-m3 reset method specified - use SYSRESETREQ (now use VECTRESET - does not reset peripherals) 2. chip reset available, cortex-m3 reset method specified - use cortex-m3 reset method that was specified What cm3 reset method would that be, for example? C code in OpenOCD? 3. chip resets available, no cortex-m3 reset method specified - use SRST Ok. 4. no chip resets, cortex-m3 reset method specified - use it, but if cortex-m3 reset method is SRST that will be changed to SYSRESETREQ (now it will be changed to VECTRESET, note as in 1.) Uh? So the cm3 reset method is not in C, but can be set to SRST? Freddie Chopin wrote: On 2010-11-11 20:47, Spencer Oliver wrote: I disagree with this patch as SYSTEMRESET is not supported as expected on all cores. Shouldn't the code assume that this standard mechanism works as the standard says? If some chip does not support it, than this chip should have VECTRESET selected in its config file, why make trouble for chips that obey this standard? I think this makes sense. If SYSRESETREQ is the standard and it is more complete then that should be the default, and those who don't support it can spec a degraded reset functionality if that's the best that can be done. I still believe the best way is for each core to state that it supports SYSTEMRESET over VECTRESET in the cfg file. I guess this is what I was asking about - how common are the two? Maybe it makes the most sense to always require explicit reset configuration in the config files. LPC2xxx supposedly cannot be reset into halted mode (because SRST pulls TRST) Please *stop* adding to this misconception! I've had to patch both lpc2148.cfg and lpc1768.cfg because someone apparently did not read the chip PDFs before making or changing the config files. It's nonsense. The whole issue is really simple IMO; each level of config file (cm3 vs. lpc1768, arm7 vs. lpc2148, etc) should reflect the accurate settings for that level, and more specific files can override more generic ones as neccessary. It's totally possible that there is no applicable default for cm3 in general, then we just don't spec anything on that level, and we make sure to add a check into openocd so that it screams at the user if no reset config has been made, when cm3 is used. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de
Re: [Openocd-development] STM32 reset_config
Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] If no SRST is available, fallback to SYSRESETREQ in Cortex-M3 soft-reset.
On 2010-11-12 00:05, Peter Stuge wrote: My perception of the situation is strongly the opposite. There is no policy, relax, there is just people working together making something generic that works. This is a difficult task. I cannot agree, as there were many discussions about whether reset_config should be placed in target file. For me it should, but for the majority of OpenOCD maintainers it shouldn't and it won't be. Number of things that users of OpenOCD have to do prior to using it for it's main purpose tends to grow, rather than shrink... Maybe things need to get a little worse before they can get a lot better. I think we're still learning about cm3. Sure, but every maintainer has different opinion on what is right and what is better, that's why nothing get's changed and the status quo will be here forever. IMO haveing target file for every supported chip (my recent proposal) is very good and _very_ user-friendly, I offered to do that, but maintainers were not interested, so this mix of family-generic (stm32, stellaris) and target-specific (lpc2103, lpc2148, at91sam7sx, at91sam7se, ...) files will probably be here forever. Completely off-topic: sometimes I think, that open-source projects are just a cover-up made by people working for big companies Sorry, this is a bit silly. I can understand that open source projects are immensely frustrating if there is some kind of incompatibility, be it attitude or philosophy or even trivial stuff like coding style. This things may seem trivial, but imagine that someone produces a patch that adds functioning support for SWD in OpenOCD and that will not be accepted, because the lines are too long... And the fact that projects to a high degree are based on voluntary contributions means that it can be basically impossible to get something done the way you like unless you do it yourself. I am not complaining that *you* do not contribute here, I mean this completely generally. Agreed, that's obvious, and no one is forcing any of the maintainers to implement someones requests. I also completely understand that not everyone can do the changes themselves, but it's also important to remember that those who selflessly do want to contribute code changes that will help others have very limited resources, so it might take time. We can get back to my previous point. If that someone had produced a monolithic SWD patch, that would also not be accepted, because changes should be incremental, easy, isolated, and so on. But imagine how this contributor would feel when he/she would be told to spend another 100 hours on refactoring the patch that took hin'her 100 hours. I would probably just write love or leave... Just remember that this is really just piece of sh*t software that we are hacking on to make it do a decent job. It is still good enough to sell products based on, and sometimes it's many many times better than proprietary products, but it is still not that amazing. Very little software is. Fixing that is of course a huge task, but we all want to make things better and try to help as best we can. It's not that I don't like OpenOCD, but how is it better than commercial software that allows one to start debug session in 3 clicks (select target model, select debugger, click connect)? This attitude may seem a bit negative, but believe me, that it's exact same attitude that a typical newcomer to ARM's world shows. Sorry, it was unclear. I meant to ask how openocd knows to use SRTS or soft-reset and if soft-reset then how it knows to use SYSRESETREQ or VECTRESET. I guess it's all target and board config files. Clarification: standard command reset_config can define that there are resets present or not. Default is none and that is assumed when no reset_config command is present. new command cortex-m3 reset_config can define reset method for Cortex-M3 core - srst (real reset, only if the signal is available, so reset_config srst is required), sysresetreq (almost-real-reset - resets peripherals) or vectreset (soft-reset that does not reset peripherals). so here is a blind answer... 1. no chip resets, no cortex-m3 reset method specified - use SYSRESETREQ (now use VECTRESET - does not reset peripherals) 2. chip reset available, cortex-m3 reset method specified - use cortex-m3 reset method that was specified What cm3 reset method would that be, for example? C code in OpenOCD? case 1 is when OpenOCD receives neither reset_config nor cortex-m3 reset_config. case 2 is when OpenOCD reveives reset_config srst / srst_and_trst and cortex-m3 reset_config srst / sysresetreq / vectreset - chip would be reset with a method specified with the latter. 3. chip resets available, no cortex-m3 reset method specified - use SRST Ok. case 3 is when OpenOCD reveives reset_config srst / srst_and_trst but no cortex-m3 reset_config ... - normal reset signal is asserted. 4. no chip resets, cortex-m3 reset method specified
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 00:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) I've tried many times, even recently - no interest in changing the status quo, discussion went on about implementing auto-discovery in OpenOCD. https://lists.berlios.de/pipermail/openocd-development/2010-November/016872.html But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. I always do. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? Imagine such case: target file defines no hardware resets and selects vectreset as the soft-reset method, as sysresetreq does not work. your file defines hardware resets effect - hardware resets are not used, vectreset is forced. To use hardware reset you have to add cortex-m3 reset_config srst. and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. But what would be the best solution? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] SPEAr serial NOR flash driver
Hi, in attachment the driver for the serial NOR flash controller of ST SPEAr devices. The first patch adds driver support and documentation, the second one adds the proper lines in the (current) only board file of this device family. The driver structure follows the prototype of the other drivers in src/flash/nor/ The file .h that I'm adding is totally useless, since only provides a function prototype but is not included by the only user of that function. In fact, the function prototype is locally re-declared in drivers.c This situation is same as in at91sam7.h Comments are welcome, as usual! Best Regards, Antonio Borneo 0001-NOR-SPEAr-Add-support-for-Serial-NOR.patch Description: Binary data 0002-TCL-SPEAr-Added-Serial-flash-in-board-file.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] lpc3131 and Actel FPGA chain programming.
On Thu, Nov 11, 2010 at 2:44 AM, Peter Stuge pe...@stuge.se wrote: Andrew Leech wrote: Now I need to figure out how to bypass the lpc via software rather than physically changing the chain. I can't seem to find much information about how bypass works with openocd, do you have any idea? Sorry, no idea. Ok I've actually got this working! From my research there's two typical ways of using a SVF on a chain, either the SVF file has to be generated to know about the chain or the jtag software has to be aware of the chain. Basically each ir and dr command needs a header and trailer padding bytes to cover the other taps on the chain. There's specific HDR and similar commands in svf to define these paddings. Some software like UrJtag ignores these commands if they even exist and figures them out itself by scanning the chain, this is neat.The svf player in openocd doesn't have anything like this (and I don't have time right now how to figure out how to add it, maybe later), so you're left with generating the svf files to be aware of the chain, if the software making the svf has this functionality. Once I have it all sorted out I think this is well worth me making a wiki page for programming fpga's on a chain, as there's not much info about it so far, and it actually seems quite easy once you know what your're doing. That would be fantastic. At the very least please do send an email with what you came up with! So yeah, I was initially generating my svf files directly from Actel Designer Software using the actel project file generated by Altium Designer (where i do the actual fpga designing). It doesn't allow you to define chains anywhere, so I though I'd be in trouble, maybe having to figure out the command manually. Looking further I found that Actel FlashPro software on the other hand allows chains to be manually defined (or detect them automatically if you have their programmer hardware plugged in), and Altium was already exporting a STAPL file by default which FlashPro was happy to assign to the fpga that was defined in the chain. Then File-Export-Chain SVF File and I had svf files complete with chain header and trailer. The basic openocd command then for me are simply: source [find interface/luminary-icdi.cfg] # My programmer source [find target/lpc3131.cfg] # This is now in mainline :) jtag_khz 6000 # Going to try to optimise this later... reset_config srst_only srst_pulls_trst # My board's only wired to do this jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf # The FPGA init scan_chain # just to be sure they're connected properly svf Chain_PROGRAM_ARRAY.svf quiet # runs my svf file from flashpro and it sits there quietly for just over 3 minutes before informing me it's all done nicely, and I have a working fpga! When I get a chance I'll make a patch/updates to the wiki page on the svf player to be a bit more explicit on how to use it. Cheers, Andrew ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
