Re: [Openocd-development] Adding support for SST 39VF6401B external flash
Hi all, It works! This was a simple matter of using auto erase with the flash. flash write_image $IMGFILE 0x8000 became: flash write_image erase $IMGFILE 0x8000 I am not sure I understand why but it works. I will create a patch containing the changes mentioned in my first message, when I get the time(unless someone else is eager to do so). With DCC+Amontec-tiny I can download at 43 kbps (4 MB in 90 seconds). Thanks for all the support anyway. Regards Flemming -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Michael Schwingen Sent: 31. december 2009 10:40 Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Adding support for SST 39VF6401B external flash David Brownell wrote: FWIW that Sparkun forum is only moderately obscure. It's the one Olimex points its customers to, and we mention it as a User's Forum in our documentation. Interesting - I did not even know about it until this thread. Do we really want to point users to a forum where the developers do not read about the problems? (In general, I refuse to read web forums except when pointed to an explicit thread. I do not bother to regularly check forums because keeping track of already-read parts combined with the lack of threading makes them a PITA). cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] ARM7/ARM9: improved reset support
Teach most remaining ARM cores how to use the reset-assert event.
Same model as elsewhere: iff a handler is provided for that event,
use that instead of trying to assert SRST (which may be unavailable);
else this code is a NOP.
Shrink some overlong lines. Add my 2009 copyright.
---
This is a bit borderline, but I'm inclined to commit for 0.4 anyway.
Comments?
It could be argued to be a new feature for ARM7/ARM9 ... or a bugfix,
since all the other ARM cores currently can be reset without SRST
(given an appropriate reset-assert event handler). Either way it's
a NOP unless you try to use this feature.
Sorry I didn't merge this a long time back (patch hasn't changed in
months, except for some comment tweaks) but the initial tests on a
platform with severe reset problems didn't go well, and I've not
touched a sanely-behaved ARM9 since then.
src/target/arm7_9_common.c | 88 +++
1 file changed, 57 insertions(+), 31 deletions(-)
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -11,6 +11,8 @@
* Copyright (C) 2008 by Hongtao Zheng *
* hon...@126.com*
* *
+ * Copyright (C) 2009 by David Brownell *
+ * *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
@@ -941,19 +943,21 @@ int arm7_9_poll(struct target *target)
int arm7_9_assert_reset(struct target *target)
{
struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
+ enum reset_types jtag_reset_config = jtag_get_reset_config();
+ bool use_event = false;
LOG_DEBUG(target-state: %s,
target_state_name(target));
- enum reset_types jtag_reset_config = jtag_get_reset_config();
- if (!(jtag_reset_config RESET_HAS_SRST))
- {
- LOG_ERROR(Can't assert SRST);
+ if (target_has_event_action(target, TARGET_EVENT_RESET_ASSERT))
+ use_event = true;
+ else if (!(jtag_reset_config RESET_HAS_SRST)) {
+ LOG_ERROR(%s: how to reset?, target_name(target));
return ERROR_FAIL;
}
- /* At this point trst has been asserted/deasserted once. We would
-* like to program EmbeddedICE while SRST is asserted, instead of
+ /* At this point trst has been asserted/deasserted once. We might
+* be able program EmbeddedICE while SRST is asserted, instead of
* depending on SRST to leave that module alone. However, many CPUs
* gate the JTAG clock while SRST is asserted; or JTAG may need
* clock stability guarantees (adaptive clocking might help).
@@ -963,7 +967,8 @@ int arm7_9_assert_reset(struct target *t
*/
bool srst_asserted = false;
- if (((jtag_reset_config RESET_SRST_PULLS_TRST) == 0)
+ if (!use_event
+!(jtag_reset_config RESET_SRST_PULLS_TRST)
(jtag_reset_config RESET_SRST_NO_GATING))
{
jtag_add_reset(0, 1);
@@ -973,48 +978,69 @@ int arm7_9_assert_reset(struct target *t
if (target-reset_halt)
{
/*
-* Some targets do not support communication while SRST is
asserted. We need to
-* set up the reset vector catch here.
+* For targets that don't support communication while SRST is
+* asserted, we need to set up the reset vector catch first.
*
-* If TRST is asserted, then these settings will be reset
anyway, so setting them
-* here is harmless.
+* When we use TRST+SRST and that's equivalent to a power-up
+* reset, these settings may well be reset anyway; so setting
+* them here won't matter.
*/
if (arm7_9-has_vector_catch)
{
- /* program vector catch register to catch reset vector
*/
-
embeddedice_write_reg(arm7_9-eice_cache-reg_list[EICE_VEC_CATCH], 0x1);
+ /* program vector catch register to catch reset */
+ embeddedice_write_reg(arm7_9-eice_cache
+ -reg_list[EICE_VEC_CATCH], 0x1);
- /* extra runtest added as issues were found with
certain ARM9 cores (maybe more) - AT91SAM9260 and STR9 */
+ /* extra runtest added as issues were found with
+* certain ARM9 cores (maybe more) - AT91SAM9260
+* and STR9
+
Re: [Openocd-development] [PATCH] atmega128: implement EEPROM flashing
On Wednesday 13 January 2010, Øyvind Harboe wrote: Seing that avr is not at the level of an official feature I don't have a problem with merging this work in progress as it does not affect any other code. It can probably be refactored easily enough. Meanwhile we can measure how much interest there is openocd + avr w/some crude support... A minor goal of mine was to throw OpenOCD at some AVR chips (AVR8 and AVR32) before 0.4 ships to see how it all behaves... assuming I get around to that, it'll be with this patch included. Perhaps there will be some feedback on minor things to change, perhaps use size_t i for iteration variable instead of uint32_t i... At some point it would be nice to sort out the various JTAG ops on AVR8. As I recall, they document only the ones used to write flash and EEPROM, and perform boundary scan. Whereas: The On-chip Debug support is considered being private JTAG instructions, and distributed within ATMEL and to selected third party vendors only. Clearly, someone needs to throw a JTAG/SPI sniffer at some of the transactions issued by AVR studio, and so some reverse engineering for interoperability. :) (I forget the story for AVR32, but at least the Nexus parts are publicly documented.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] atmega128: implement EEPROM flashing
On Thu, Jan 14, 2010 at 12:16:59AM -0800, David Brownell wrote: On Wednesday 13 January 2010, ?yvind Harboe wrote: Seing that avr is not at the level of an official feature I don't have a problem with merging this work in progress as it does not affect any other code. It can probably be refactored easily enough. Meanwhile we can measure how much interest there is openocd + avr w/some crude support... A minor goal of mine was to throw OpenOCD at some AVR chips (AVR8 and AVR32) before 0.4 ships to see how it all behaves... assuming I get around to that, it'll be with this patch included. Thanks. Do you think it worth introducing additional custom avrf commands for reading flash and eeprom with the documented jtag commands? I'm sure memory-mapped way will not work in the nearest future and having any way to dump current firmware would already be nice (to at least verify the flashing). Probably also some tcl script can be added to automate flashing/verifying process, especially considering the fact that windows doesn't have tools to e.g. strip tailing 0xFFs before file comparision. Perhaps there will be some feedback on minor things to change, perhaps use size_t i for iteration variable instead of uint32_t i... Well, that was just a copy-paste of the code which already was there for flash. I assume the intention of the original author to use the same type for i as he used for the upper boundary in the for cycle. At some point it would be nice to sort out the various JTAG ops on AVR8. As I recall, they document only the ones used to write flash and EEPROM, and perform boundary scan. Whereas: Also fuse settings (which are important enough and for most devices need to be changed from the default) and reading all of those back. The On-chip Debug support is considered being private JTAG instructions, and distributed within ATMEL and to selected third party vendors only. Clearly, someone needs to throw a JTAG/SPI sniffer at some of the transactions issued by AVR studio, and so some reverse engineering for interoperability. :) Luckily someone already did that, see [1] (they used Free AVR ICE to sniff). [1] http://mirrors.igsobe.com/nongnu/freeice/AVR-OCD-Documentation.html -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] ARM7/ARM9: improved reset support
At this late stage, I would like to have this patch split into overlong lines and *actual* changes. That makes the patch easier to review for potential regressions. Actually, just push the overlong line fixes first... -- Øyvind Harboe 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
[Openocd-development] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target.
I tried to erase all the contents of the flash, sectors 0 to 7. Commands:
reset init
flash erase_address 0 0x8 (or flash erase_sector 0 0 7)
The expected result is:
erased sectors 0 through 7 on flash bank 0 in x.xxs
but instead the command returned erase timed out:
erase timed out
failed erasing sectors 0 to 7 (-4)
Here are the last lines of the logs:
Debug: 25605 4184220 arm7_9_common.c:2210 arm7_9_read_memory():
address: 0x, size: 0x0001, count: 0x0001
Debug: 25606 4184220 target.c:1527 target_read_u8(): address: 0x,
value: 0x00
Error: 25607 4184220 str9x.c:278 str9x_erase(): erase timed out
Error: 25608 4184230 core.c:48 flash_driver_erase(): failed erasing sectors
0 to 7 (-4)
It worked fine when the process was divided in two: started with the first 7
(0 to 6) sectors and then erased the last one, sector #7 separately.
Using the erase bank command will cause a time out error. Replacing
this with the erase sector bank will provide a slower but safer and
stable method to erase the flash.
Signed-off-by: Laurentiu Cocanu laurentiu.coc...@zylin.com
---
src/flash/nor/str9x.c | 18 +++---
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index bf3f750..d0c1278 100644
--- a/src/flash/nor/str9x.c
+++ b/src/flash/nor/str9x.c
@@ -230,17 +230,9 @@ static int str9x_erase(struct flash_bank *bank, int first,
int last)
return ERROR_TARGET_NOT_HALTED;
}
- /* Check if we erase whole bank */
- if ((first == 0) (last == (bank-num_sectors - 1)))
- {
- /* Optimize to run erase bank command instead of sector */
- erase_cmd = 0x80;
- }
- else
- {
- /* Erase sector command */
- erase_cmd = 0x20;
- }
+ /*A slower but stable way of erasing*/
+ /* Erase sector command */
+ erase_cmd = 0x20;
for (i = first; i = last; i++)
{
@@ -296,10 +288,6 @@ static int str9x_erase(struct flash_bank *bank, int first,
int last)
LOG_ERROR(error erasing flash bank, status: 0x%x,
status);
return ERROR_FLASH_OPERATION_FAILED;
}
-
- /* If we ran erase bank command, we are finished */
- if (erase_cmd == 0x80)
- break;
}
for (i = first; i = last; i++)
--
1.6.0.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
Laurentiu Cocanu wrote: I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target. I tried to erase all the contents of the flash, sectors 0 to 7. Commands: reset init flash erase_address 0 0x8 (or flash erase_sector 0 0 7) The expected result is: erased sectors 0 through 7 on flash bank 0 in x.xxs but instead the command returned erase timed out: erase timed out failed erasing sectors 0 to 7 (-4) Probably worth changing, this is how i originally wrote the driver anyway :) it may even be a arm966e_write_cp15 bug. The str9 has a bug that effects the fmi status reg if the TCM bit is not set. This would normally be done by str9x flash_config, may need checking it still works. http://www.st.com/stonline/products/literature/es/12944.pdf Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
On Thu, Jan 14, 2010 at 2:39 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Laurentiu Cocanu wrote: I tested version v0.4.0-rc1-98-g6c75f52 of OpenOCD for STR912 target. I tried to erase all the contents of the flash, sectors 0 to 7. Commands: reset init flash erase_address 0 0x8 (or flash erase_sector 0 0 7) The expected result is: erased sectors 0 through 7 on flash bank 0 in x.xxs but instead the command returned erase timed out: erase timed out failed erasing sectors 0 to 7 (-4) Probably worth changing, this is how i originally wrote the driver anyway :) it may even be a arm966e_write_cp15 bug. The str9 has a bug that effects the fmi status reg if the TCM bit is not set. This would normally be done by str9x flash_config, may need checking it still works. http://www.st.com/stonline/products/literature/es/12944.pdf So do we apply the patch or not? -- Øyvind Harboe 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
[Openocd-development] JTAG cables out there
I'm trying to get a sense for what cables are used out there. What would you guys expect to get with a JTAG debugger? The most common seems to be the JTAG 20 cable. I've seen JTAG 14 on an older AT91EB40a. Ultimately I would expect to users to solder their own custom JTAG cable for smaller footprint application PCBs... I've seen this a lot. Flying leads sounds nice, but it wouldn't have replaced hand soldered solutions where I've seen them. I've seen JTAG 20 used with SWD. Is there a smaller SWD connector? -- Øyvind Harboe 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] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
http://www.st.com/stonline/products/literature/es/12944.pdf So do we apply the patch or not? i would say yes, as it only slows the erase a little. Just for info have you tried increasing the timeout? The silicon you have may be getting old. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver s...@spen-soft.co.uk wrote: http://www.st.com/stonline/products/literature/es/12944.pdf So do we apply the patch or not? i would say yes, as it only slows the erase a little. Will do. Just for info have you tried increasing the timeout? No. We're just trying to get a wide range of targets tests, so we don't want to linger on this one. The silicon you have may be getting old. Cheers Spen -- Øyvind Harboe 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
[Openocd-development] Warning: cross-compilation to windows on Debian is broken
Hi, I want to try to help those poor souls who'll face the same bug trying to use a cross-compiled windows binary made with Debian's mingw. First, do not forget to #include limits.h before compling the openocd sources. Second, you need to recompile mingw-runtime due to [1]. The bug hits badly every time %ld is used in a format string, beware. HTH [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452977 -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] str9x.c: take2: Removed the optimization when erasing the whole bank
Øyvind Harboe wrote: On Thu, Jan 14, 2010 at 3:02 PM, Spencer Oliver s...@spen-soft.co.uk wrote: http://www.st.com/stonline/products/literature/es/12944.pdf So do we apply the patch or not? i would say yes, as it only slows the erase a little. Will do. Just for info have you tried increasing the timeout? No. We're just trying to get a wide range of targets tests, so we don't want to linger on this one. The docs say a maximum timeout of 11.5secs for the largest bank (512k). Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG cables out there
Hi, On 2010.01.14 15:52, Øyvind Harboe wrote: I'm trying to get a sense for what cables are used out there. What would you guys expect to get with a JTAG debugger? The most common seems to be the JTAG 20 cable. I've seen JTAG 14 on an older AT91EB40a. Ultimately I would expect to users to solder their own custom JTAG cable for smaller footprint application PCBs... I've seen this a lot. Flying leads sounds nice, but it wouldn't have replaced hand soldered solutions where I've seen them. I've seen JTAG 20 used with SWD. Is there a smaller SWD connector? The JTAG/SWD cable with small 10 pin 1.27mm pitch connector like the one on MCB1700 board: http://www.keil.com/support/man/docs/mcb1700/mcb1700_to_jtag.htm would be great to get. The Code Red board RBC1768 I previously had also had such connector with equivalent pinout (except for pin 7, which is populated here), which makes me think about some existing standard: http://support.code-red-tech.com/CodeRedWiki/RDB1768Support Regards, Audrius Urmanavicius ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] GDB: change gdb_breakpoint_override to COMMAND_ANY
Øyvind Harboe wrote: I am a bit bemused by this. GDB will have a good copy of the registers when it connects to openocd anyway. Not necessarily true: target remote load monitor reg = GDB is out of sync stepi = gdb is in sync here. but surely the regs should be saved/restored by openocd during the gdb load? the actual target will be out of sync after the load (until next resume/step), but cannot see how openocd/gdb becomes out of sync. Not important, may dig deeper when i have a minute. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] GDB: change gdb_breakpoint_override to COMMAND_ANY
On Thu, Jan 14, 2010 at 4:05 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Øyvind Harboe wrote: I am a bit bemused by this. GDB will have a good copy of the registers when it connects to openocd anyway. Not necessarily true: target remote load monitor reg = GDB is out of sync stepi = gdb is in sync here. but surely the regs should be saved/restored by openocd during the gdb load? The problem is that openocd or the target state can change behind GDB's back. E.g. if you power cycle the target while connected to GDB, or hotplug. There are *raft* of issues and I don't recall them all. Basically the assumption that OpenOCD, GDB and the target are in sync is seriously flawed on all levels. Especially for hardware type debugging like openocd. E.g. now connecting with to GDB is a no-operation. It does not affect the target state. This means that it is possible to connect to GDB and issue GDB monitor commands to bring the target into the correct state before GDB starts talking to it. The target could be running or halted during GDB connect. The stepi synchronizes GDB to the target stage, i.e. if the target was running while GDB was connected, stepi will not return until the target halts. I posted several messages on the gdb_sync issues, here's one: http://lists.berlios.de/pipermail/openocd-development/2009-September/010779.html -- Øyvind Harboe 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] [PATCH] nand flash support for s3c64xx
On Wed, Jan 13, 2010 at 9:48 PM, Peter Korsgaard jac...@sunsite.dk wrote: Øyvind == Øyvind Harboe oyvind.har...@zylin.com writes: Øyvind To me this patch looks reasonable. the .c file is basically a bunch Øyvind of parameters and a few lines of code. Øyvind Perhaps later the code could be refactored to share more, but Øyvind pre 0.4 I think there is something to be said for not touching the Øyvind existing drivers. OK. I'm fine with reworking the s3c nand support post-0.4. Pushed. -- Øyvind Harboe 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] JTAG cables out there
On Thursday 14 January 2010, Audrius Urmanavicius wrote: I've seen JTAG 20 used with SWD. Is there a smaller SWD connector? The JTAG/SWD cable with small 10 pin 1.27mm pitch connector like the one on MCB1700 board: http://www.keil.com/support/man/docs/mcb1700/mcb1700_to_jtag.htm would be great to get. That 10-pin JTAG/SWD (with 0.05 pin spacing) is getting common. There's a related 20-pin (with 0.05 pin spacing) connector, which adds support for a narrow (up to 4 bit wide) trace port. Also smaller than traditional ARM 20-pin (with 0.10 pin spacing). Both those connectors are specified in some ARM document I've seen. The compactness is nice. The pin spacing isn't; that's at best awkward to solder, and those small IDC cables are hard to find or make. Re what I'd expect to see ... that's a function of the devices I expect to use with the product. For ARM, standard 20-pin/0.10 for sure; but with a forward-looking hat, I'd think about 10-pin SWD/JTAG too. If I were using it with TI parts, the TI-14. AVR uses a 10-pin/0.10 Altera variant; etc. Having a flying-leads octopus option wins flexibility, of course, but mostly for random one-off configs not heavy use. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
Any comments on this? I had hoped to get this functional in 0.4 so I could drop the -s from the command line at work. Windows builders/packagers, does this look OK from your point of view or do you still install scripts in ../lib? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
On Thursday 14 January 2010, Andreas Fritiofson wrote: Any comments on this? I was hoping some Windows users would comment .. I had hoped to get this functional in 0.4 so I could drop the -s from the command line at work. Windows builders/packagers, does this look OK from your point of view or do you still install scripts in ../lib? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's the meaning of argument handle_breakpoints in function target_resume() ?
Hmm ... is this a bug you've observed, or is this something you've wondered after poking through the code? I recall setting breakpoints through the Tcl interface and having them behave correctly. Haven't tried to do that any time recently, though. And I could believe there's a bit of a semantic conflict between debug via GDB and via Tcl; not one we want, of course!! I found that the breakpoint and step operations take no effect when debugging with GDB while everything is OK in TCL interfaces. Then I found the problem after poking through the code. The problem is resolved when I modified gdb_step_continue_packet() in gdb_server.c by calling target_resume() with handle_breakpoints=true which is false originally. But I'm not sure weather the modification is correct because we can see from the code below that the designer had done that in special purpose. retval = target_resume(target, current, address, 0, 0); /* resume at current address, don't handle breakpoints, not debugging */ _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/rfc 0/3] TMS clocking interface
This is one of several low-level interface changes that will support SWD ... obviously not for the 0.4 release, but I'm posting it now as an FYI/RFC. - Interface level patch: add a call to clock bits out on TMS. Switching between JTAG and SWD modes involves some magic sequences here. The same mechanism is general enough to handle the JTAG state machine too, moving it up a level (into the JTAG midlayer) for JTAG adapters that want it. - Use that from the midlayer, if the underlying JTAG adapter driver supports the mechanism (most could) ... helps drivers avoid needless differences in JTAG state transitions. - Implement FT2232 support. In short ... this is structured to be useful even without SWD. Other low level changes to support SWD will address things like individual request/response transactions, plus link and target initialization updates. Plus ideally some cleanup of the interfaces at the JTAG level, to address the fact that not all debug links are JTAG, and that some of them can switch between JTAG and SWD modes. See the first patch for some comments reflecting my thoughts there. I think the rest will be higher level things, at the level of ADIv5 being aware of which transport to use. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/rfc 1/3] interface: define TMS sequence command
For support of SWD we need to be able to clock out special bit
sequences over TMS or SWDIO. Create this as a generic operation,
not yet called by anything, which is split as usual into:
- upper level abstraction ... here, jtag_add_tms_seq();
- midlayer implementation logic hooking that to the lowlevel code;
- lowlevel minidriver operation ... here, interface_add_tms_seq();
- message type for request queue, here JTAG_TMS.
This is done slightly differently than other operations: there's a flag
saying whether the interface driver supports this request. (In fact a
flag word, so the midlayer can learn about other capabilities too.)
That will let this method be used to eliminate pathmove() and statemove()
support from most adapter drivers, which will increase uniformity (and
thus reduce subtle bugginess) even for SWD-incapable hardware.
---
src/jtag/commands.h| 39 ++-
src/jtag/core.c| 37 +
src/jtag/drivers/driver.c | 20
src/jtag/interface.h | 18 ++
src/jtag/jtag.h|2 ++
src/jtag/minidriver.h |2 ++
src/jtag/minidummy/minidummy.c |7 +++
src/jtag/zy1000/zy1000.c | 11 ++-
8 files changed, 126 insertions(+), 10 deletions(-)
--- a/src/jtag/commands.h
+++ b/src/jtag/commands.h
@@ -99,18 +99,38 @@ struct sleep_command {
};
/**
+ * Encapsulates a series of bits to be clocked out, affecting state
+ * and mode of the interface.
+ *
+ * In JTAG mode these are clocked out on TMS, using TCK. They may be
+ * used for link resets, transitioning between JTAG and SWD modes, or
+ * to implement JTAG state machine transitions (instead of using
+ * pathmove or statemove commands).
+ *
+ * In SWD mode these are clocked out on SWDIO, using SWCLK, and are
+ * used for link resets and transitioning between SWD and JTAG modes.
+ */
+struct tms_command {
+ /** How many bits should be clocked out. */
+ unsignednum_bits;
+ /** The bits to clock out; the LSB is bit 0 of bits[0]. */
+ uint8_t *bits;
+};
+
+/**
* Defines a container type that hold a pointer to a JTAG command
* structure of any defined type.
*/
union jtag_command_container {
- struct scan_command* scan;
- struct statemove_command*statemove;
- struct pathmove_command* pathmove;
- struct runtest_command* runtest;
- struct stableclocks_command* stableclocks;
- struct reset_command*reset;
- struct end_state_command*end_state;
- struct sleep_command* sleep;
+ struct scan_command *scan;
+ struct statemove_command*statemove;
+ struct pathmove_command *pathmove;
+ struct runtest_command *runtest;
+ struct stableclocks_command *stableclocks;
+ struct reset_command*reset;
+ struct end_state_command*end_state;
+ struct sleep_command*sleep;
+ struct tms_command *tms;
};
/**
@@ -124,7 +144,8 @@ enum jtag_command_type {
JTAG_RESET= 4,
JTAG_PATHMOVE = 6,
JTAG_SLEEP= 7,
- JTAG_STABLECLOCKS = 8
+ JTAG_STABLECLOCKS = 8,
+ JTAG_TMS = 9,
};
struct jtag_command {
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -488,6 +488,43 @@ void jtag_add_tlr(void)
jtag_notify_event(JTAG_TRST_ASSERTED);
}
+/**
+ * If supported by the underlying adapter, this clocks a raw bit sequence
+ * onto TMS for switching betwen JTAG and SWD modes.
+ *
+ * DO NOT use this to bypass the integrity checks and logging provided
+ * by the jtag_add_pathmove() and jtag_add_statemove() calls.
+ *
+ * @param nbits How many bits to clock out.
+ * @param seq The bit sequence. The LSB is bit 0 of seq[0].
+ * @param state The JTAG tap state to record on completion, either
+ * TAP_INVALID (for switching to SWD mode) or TAP_RESET (for
+ * switching to JTAG mode).
+ *
+ * @todo Update naming conventions to stop assuming everything is JTAG.
+ */
+int jtag_add_tms_seq(unsigned nbits, uint8_t *seq, enum tap_state state)
+{
+ int retval;
+
+ if (!(jtag-supported DEBUG_CAP_TMS_SEQ))
+ return ERROR_JTAG_NOT_IMPLEMENTED;
+
+ switch (state) {
+ case TAP_INVALID:
+ case TAP_RESET:
+ jtag_checks();
+ cmd_queue_cur_state = state;
+ break;
+ default:
+ return ERROR_JTAG_STATE_INVALID;
+ }
+
+ retval = interface_add_tms_seq(nbits, seq);
+ jtag_set_error(retval);
+ return retval;
+}
+
void jtag_add_pathmove(int num_states, const tap_state_t *path)
{
tap_state_t cur_state = cmd_queue_cur_state;
--- a/src/jtag/drivers/driver.c
+++ b/src/jtag/drivers/driver.c
@@ -388,6 +388,26 @@ int interface_jtag_add_tlr(void)
[Openocd-development] [patch/rfc 2/3] JTAG: use new TMS sequence command
When the underlying JTAG adapter supports it, use the new TMS sequence
operation instead of a pathmove(). This will eliminate duplicated work,
and removes the need for separate pathmove() logic in those drivers.
Similarly for statemove() ... which someday we might consider removing.
It's already redundant, given pathmove().
Note that this moves a paths may have at most 32 elements constraint
into the core. The FT2232 code has it as an assertion, which we don't
seem to have triggered ... so this can't be a real problem. There are
only 16 JTAG states, so long paths wouldn't be useful anyway. Note that
the Jim pathmove command tops out at 8, and the XSVF logic breaks paths
into segments at stable states; so producing even a 32-element path is
pretty unlikely.
---
src/jtag/core.c | 66 -
src/jtag/interface.c |2 -
src/jtag/interface.h |4 +-
3 files changed, 57 insertions(+), 15 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -528,6 +528,18 @@ int jtag_add_tms_seq(unsigned nbits, uin
void jtag_add_pathmove(int num_states, const tap_state_t *path)
{
tap_state_t cur_state = cmd_queue_cur_state;
+ uint32_t tms_path = 0;
+
+ /* For now, reject long paths instead of trying to segment them
+* when going through some stable state. We don't seem to have
+* any call paths which could trigger this, in any case.
+*/
+ if (num_states 32) {
+ LOG_ERROR(JTAG path length %d is too long! Shorten it.,
+ num_states);
+ jtag_set_error(ERROR_JTAG_TRANSITION_INVALID);
+ return;
+ }
/* the last state has to be a stable state */
if (!tap_is_state_stable(path[num_states - 1]))
@@ -546,15 +558,34 @@ void jtag_add_pathmove(int num_states, c
return;
}
- if (tap_state_transition(cur_state, true) != path[i]
- tap_state_transition(cur_state, false) != path[i])
- {
- LOG_ERROR(BUG: %s - %s isn't a valid TAP transition,
- tap_state_name(cur_state),
tap_state_name(path[i]));
- jtag_set_error(ERROR_JTAG_TRANSITION_INVALID);
- return;
+ if (tap_state_transition(cur_state, true) == path[i]) {
+ cur_state = path[i];
+ tms_path |= 1 i;
+ DEBUG_JTAG_IO(JTAG: -- %s,
+ tap_state_name(cur_state));
+ continue;
}
- cur_state = path[i];
+ if (tap_state_transition(cur_state, false) == path[i]) {
+ cur_state = path[i];
+ DEBUG_JTAG_IO(JTAG: -- %s,
+ tap_state_name(cur_state));
+ continue;
+ }
+
+ LOG_ERROR(BUG: %s - %s isn't a valid TAP transition,
+ tap_state_name(cur_state),
+ tap_state_name(path[i]));
+ jtag_set_error(ERROR_JTAG_TRANSITION_INVALID);
+ return;
+ }
+
+ /* Can we pass that TMS sequence directly to the driver? */
+ if (jtag-supported DEBUG_CAP_TMS_SEQ) {
+ uint8_t tms[4];
+
+ buf_set_u32(tms, 0, 32, tms_path);
+ jtag_add_tms_seq(num_states, tms, path[num_states - 1]);
+ return;
}
jtag_checks();
@@ -580,12 +611,20 @@ int jtag_add_statemove(tap_state_t goal_
else if (goal_state == cur_state)
/* nothing to do */ ;
- else if (tap_is_state_stable(cur_state)
tap_is_state_stable(goal_state))
+ else if (tap_is_state_stable(cur_state)
+tap_is_state_stable(goal_state))
{
- unsigned tms_bits = tap_get_tms_path(cur_state, goal_state);
- unsigned tms_count = tap_get_tms_path_len(cur_state,
goal_state);
+ uint8_t tms_bits = tap_get_tms_path(cur_state, goal_state);
+ unsigned tms_count;
+
+ tms_count = tap_get_tms_path_len(cur_state, goal_state);
+
+ /* Can we pass that TMS sequence directly to the driver? */
+ if (jtag-supported DEBUG_CAP_TMS_SEQ)
+ return jtag_add_tms_seq(tms_count, tms_bits,
+ goal_state);
+
tap_state_t moves[8];
- assert(tms_count ARRAY_SIZE(moves));
for (unsigned i = 0; i tms_count; i++, tms_bits = 1)
{
@@ -600,6 +639,9 @@ int jtag_add_statemove(tap_state_t goal_
else if (tap_state_transition(cur_state, true) == goal_state
|| tap_state_transition(cur_state, false) == goal_state)
{
+ /* REVISIT
[Openocd-development] [patch/rfc 3/3] ft2232: implement TMS sequence command
Implement the new TMS_SEQ command on FT2232 hardware, and remove
its now un-needed pathmove() support. This is a net minor code
shrink in this driver, combined with the feature addition.
Also, swap a bogus exit() call with a clean failure return.
---
src/jtag/drivers/ft2232.c | 133 +++-
1 file changed, 58 insertions(+), 75 deletions(-)
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -767,64 +767,6 @@ static int ft2232_send_and_recv(struct j
return retval;
}
-/**
- * Function ft2232_add_pathmove
- * moves the TAP controller from the current state to a new state through the
- * given path, where path is an array of tap_state_t's.
- *
- * @param path is an array of tap_stat_t which gives the states to traverse
through
- * ending with the last state at path[num_states-1]
- * @param num_states is the count of state steps to move through
- */
-static void ft2232_add_pathmove(tap_state_t* path, int num_states)
-{
- int state_count = 0;
-
- assert((unsigned) num_states = 32u); /* tms_bits only holds
32 bits */
-
- DEBUG_JTAG_IO(-);
-
- /* this loop verifies that the path is legal and logs each state in the
path */
- while (num_states)
- {
- unsigned char tms_byte = 0; /* zero this on each MPSSE
batch */
- int bit_count = 0;
- int num_states_batch = num_states 7 ? 7 :
num_states;
-
- /* command Clock Data to TMS/CS Pin (no Read) */
- buffer_write(0x4b);
-
- /* number of states remaining */
- buffer_write(num_states_batch - 1);
-
- while (num_states_batch--) {
- /* either TMS=0 or TMS=1 must work ... */
- if (tap_state_transition(tap_get_state(), false)
- == path[state_count])
- buf_set_u32(tms_byte, bit_count++, 1, 0x0);
- else if (tap_state_transition(tap_get_state(), true)
- == path[state_count])
- buf_set_u32(tms_byte, bit_count++, 1, 0x1);
-
- /* ... or else the caller goofed BADLY */
- else {
- LOG_ERROR(BUG: %s - %s isn't a valid
- TAP state transition,
- tap_state_name(tap_get_state()),
- tap_state_name(path[state_count]));
- exit(-1);
- }
-
- tap_set_state(path[state_count]);
- state_count++;
- num_states--;
- }
-
- buffer_write(tms_byte);
- }
- tap_set_end_state(tap_get_state());
-}
-
static void ft2232_add_scan(bool ir_scan, enum scan_type type, uint8_t*
buffer, int scan_size)
{
int num_bytes = (scan_size + 7) / 8;
@@ -1618,22 +1560,23 @@ static int ft2232_execute_statemove(stru
return retval;
}
-static int ft2232_execute_pathmove(struct jtag_command *cmd)
+/**
+ * Clock a bunch of TMS (or SWDIO) transitions, to change the JTAG
+ * (or SWD) state machine.
+ */
+static int ft2232_execute_tms(struct jtag_command *cmd)
{
- int predicted_size = 0;
- int retval = ERROR_OK;
-
- tap_state_t* path = cmd-cmd.pathmove-path;
- int num_states= cmd-cmd.pathmove-num_states;
+ int retval = ERROR_OK;
+ unsignednum_bits = cmd-cmd.tms-num_bits;
+ uint8_t *bits = cmd-cmd.tms-bits;
+ unsignedcount;
- DEBUG_JTAG_IO(pathmove: %i states, current: %s end: %s, num_states,
- tap_state_name(tap_get_state()),
- tap_state_name(path[num_states-1]));
+ LOG_INFO(TMS: %d bits, num_bits);
+// DEBUG_JTAG_IO(TMS: %d bits, num_bits);
/* only send the maximum buffer size that FT2232C can handle */
- predicted_size = 3 * DIV_ROUND_UP(num_states, 7);
- if (ft2232_buffer_size + predicted_size + 1 FT2232_BUFFER_SIZE)
- {
+ count = 3 * DIV_ROUND_UP(num_bits, 4);
+ if (ft2232_buffer_size + count + 1 FT2232_BUFFER_SIZE) {
if (ft2232_send_and_recv(first_unsent, cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
@@ -1641,9 +1584,46 @@ static int ft2232_execute_pathmove(struc
first_unsent = cmd;
}
- ft2232_add_pathmove(path, num_states);
- require_send = 1;
+ /* Shift out in batches of at most 6 bits; there's a report of an
+* FT2232 bug in this area, where shifting exactly 7 bits can make
+* problems with TMS signaling for the last clock cycle:
+*
+*
Re: [Openocd-development] What's the meaning of argument handle_breakpoints in function target_resume() ?
On Thursday 14 January 2010, yintang gu wrote: Hmm ... is this a bug you've observed, or is this something you've wondered after poking through the code? I recall setting breakpoints through the Tcl interface and having them behave correctly. Haven't tried to do that any time recently, though. And I could believe there's a bit of a semantic conflict between debug via GDB and via Tcl; not one we want, of course!! I found that the breakpoint and step operations take no effect when debugging with GDB while everything is OK in TCL interfaces. That's pretty odd... I have no idea why they are set up to act differently. Then I found the problem after poking through the code. The problem is resolved when I modified gdb_step_continue_packet() in gdb_server.c by calling target_resume() with handle_breakpoints=true which is false originally. But I'm not sure weather the modification is correct because we can see from the code below that the designer had done that in special purpose. retval = target_resume(target, current, address, 0, 0); /* resume at current address, don't handle breakpoints, not debugging */ Yeah, that's kind of puzzling. GDB says not to handle breakpoints, so the target resumes without handling breakpoints -- as requested. And then GDB misbehaves??? Evidently handle is being used to mean something pretty odd. (Just like debugging, for that matter...) I'll hope someone else chimes in with some insights here. This kind of needs to get sorted before 0.4 freezes. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
On Thu, Jan 14, 2010 at 11:26 PM, David Brownell davi...@pacbell.net wrote: On Thursday 14 January 2010, Andreas Fritiofson wrote: Any comments on this? I was hoping some Windows users would comment .. I find it that none has. -- Øyvind Harboe 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] [PATCH 2/3] update win32 script search path
On Fri, Jan 15, 2010 at 8:18 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Thu, Jan 14, 2010 at 11:26 PM, David Brownell davi...@pacbell.net wrote: On Thursday 14 January 2010, Andreas Fritiofson wrote: Any comments on this? I was hoping some Windows users would comment .. I find it that none has. arrg... send too soon: I find it odd that none has. -- Øyvind Harboe 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] What's the meaning of argument handle_breakpoints in function target_resume() ?
I'll hope someone else chimes in with some insights here. This kind of needs to get sorted before 0.4 freezes. Here is another tidbit: If you execute c, then first a step packet is sent, then a continue packet. Weird, uh? -- Øyvind Harboe 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] [patch/rfc 1/3] interface: define TMS sequence command
+struct tms_command {
+ /** How many bits should be clocked out. */
+ unsigned num_bits;
+ /** The bits to clock out; the LSB is bit 0 of bits[0]. */
+ uint8_t *bits;
Tiny comment:
Use uint32_t here, rather than 8 bits. Why 8 bits? There is no
big/small endian issue here, lsb is shifted out first.
The only reason I mention this is because I'd like to see the rest of
the jtag api move away from 8 bit vectors to something more sensible
(32 really).
--
Øyvind Harboe
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] [patch/rfc 0/3] TMS clocking interface
I'm OK with this patch. I'll follow up on it for zy1000 once you push it post 0.5. I had a *minor* comment about not using 8 bit in bit arrays, but my primary concerns have more to do with not disturbing your momentum. :-) -- Øyvind Harboe 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] [PATCH 2/3] update win32 script search path
Użytkownik oyvind.har...@zylin.com napisał: I find it odd that none has. Personally I don't know what is the point of that patch. I don't use OpenOCD via tree of MinGW/MSYS and I don't think anyone does, so what's the point of that patch? I use MinGW/MSYS to compile OpenOCD, and it compiles fine, because that process does not require cfg files. In windows there is only one place for installing software - C:\Program Files\. Personally I package OpenOCD the same way as Michael Fisher has done that in the past: /bin/ (exe + dll), /interface/ (cfg), /target/ (cfg), /board/ (cfg) and that works as a charm. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
