Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
BTW - I've posted the compiled version on my website (www.freddiechopin.info) for ppl to test. Cheers! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On 2010-04-20 09:46, Andreas Fritiofson wrote: Freddie, have you checked if the patch resolves your problem? I managed to check that today (sorry for delay). Current master (with the merged patch) fixes the "first gdb load" issue completely for me. Everything else regarding the stm32 chip works fine, so I guess that the bug can be closed now: http://sourceforge.net/apps/trac/openocd/ticket/5 Thanks for fixing that issue! (; Cheers! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On Tue, Apr 20, 2010 at 9:08 AM, Øyvind Harboe wrote: > I've updated the documentation on the gdb-attach event to > provide an alternate way to solve this issue. > Great! And there's the target event list that I was briefly searching for. Good to know there is one. Freddie, have you checked if the patch resolves your problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
I've updated the documentation on the gdb-attach event to provide an alternate way to solve this issue. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.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] stm32x: allow flash probe on a running target
Merged. I would still like to see a more robust general solution to this problem, but identifying it is a very good start... -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.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] stm32x: allow flash probe on a running target
I think you make some good points specifically for this target. I'll let this patch cool off + await for feedback on this discussion before considering merging. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.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] stm32x: allow flash probe on a running target
On Sat, Apr 17, 2010 at 9:40 AM, Øyvind Harboe wrote: > You have found an interesting case here indeed. > > As a principle it should be possible to connect via GDB regardless > of the target state. > > Since that state, in general, can include a case where the target's > flash is not probable and we need the flash layout upon connection, > I think we need a more general solution than the one you have below. > Also, I think it is good, in general, to require the target to be halted > before the flash is probed GDB aside. Well, many targets DO need to be halted to be able to probe the flash and I agree that it would be nice with a solution to the GDB connect problem in the general case. However, I don't see how it helps to impose artificial restrictions to targets/flash drivers that are free from such limitations. I believe such restrictions should be removed, regardless of any general solution. Besides, if we for some reason would want the target to always be halted before a flash probe, shouldn't that be enforced in the generic flash layer instead of in each individual driver? > I would like a robust and simple solution. This is not a common problem, > it is the first time that it has been spotted. A solution that made the > general > case harder would not be desirable. I don't know, I somehow recall previous reports of this kind of problem, earlier than Freddie's. And I suspect there's a vast number of problems like this that never get reported, since people are historically used to having random glitches and occasional malfunction. Restarting GDB/OpenOCD is easier than reporting the bug. For sure it's been a long-standing major annoyance at work with those once-in-a-while failed loads. I just haven't found a cause until now (there may be other as well). > Did you consider adding target config script code to a pre connect > GDB event? > > Such an event could reset init the target if the flash is not probe-able. I did consider, but refrained for three reasons: 1. I couldn't find a reference to the available hooks in the documentation, and I don't know them by heart. I'm sure I just didn't look hard enough. 2. That would be somewhat of a workaround and I'd much rather see a fix for the underlying problem. 3. It would probably make it impossible to connect to a running target without stopping it, for the cases where it is desired. This may be a good solution for targets which are impossible to probe in the running state. Other targets shouldn't need it. -- Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
On 2010-04-17 09:40, Øyvind Harboe wrote: I would like a robust and simple solution. This is not a common problem, it is the first time that it has been spotted. I believe that the problem spotted here is the reason for this bug reported by me a while ago: https://lists.berlios.de/pipermail/openocd-development/2010-January/014223.html I'll try the patch later... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] stm32x: allow flash probe on a running target
You have found an interesting case here indeed. As a principle it should be possible to connect via GDB regardless of the target state. Since that state, in general, can include a case where the target's flash is not probable and we need the flash layout upon connection, I think we need a more general solution than the one you have below. Also, I think it is good, in general, to require the target to be halted before the flash is probed GDB aside. I would like a robust and simple solution. This is not a common problem, it is the first time that it has been spotted. A solution that made the general case harder would not be desirable. Did you consider adding target config script code to a pre connect GDB event? Such an event could reset init the target if the flash is not probe-able. -- Meet Zylin at ESC 2010 San Jose April 26 - 30. 2010 http://www.zylin.com/events_esc2010.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
[Openocd-development] [PATCH] stm32x: allow flash probe on a running target
If the flash has not yet been probed and GDB connects while the target is
running, the flash probe triggered by GDB's memory map read will fail. In
that case the returned memory map will be empty, causing a subsequent load
from within GDB to fail. There's not much you can do from GDB to recover,
other than a restart; a 'mon reset init' and manual 'mon flash probe' won't
help since GDB has already made up its mind about the memory map.
It seems there's no reason to require the target to be halted when probing
the flash. Remove the check to let a valid memory map be provided to GDB
even when connecting to a running target.
Signed-off-by: Andreas Fritiofson
---
src/flash/nor/stm32x.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c
index 845d589..818c474 100644
--- a/src/flash/nor/stm32x.c
+++ b/src/flash/nor/stm32x.c
@@ -676,12 +676,6 @@ static int stm32x_probe(struct flash_bank *bank)
uint32_t device_id;
int page_size;
- if (bank->target->state != TARGET_HALTED)
- {
- LOG_ERROR("Target not halted");
- return ERROR_TARGET_NOT_HALTED;
- }
-
stm32x_info->probed = 0;
/* read stm32 device id register */
--
1.6.3.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
