Re: [Openocd-development] STM32: flash write_image has an alignment issue and flash protect/erase is broken
Maybe the following example (output is pasted below) can illustrate the issue
a bit better. First I try to flash a 20KB block, then a 21KB block and
finally a 24KB block. Only the blocks of 20 and 24 succeed, because they
happen
to be nicely 4K alligned. All blocks that are not 4K alligned will fail.
OpenOCD
tries to erase, (un)protect and flash only those sectors that are modified,
but doesn't take into account that some platforms require certain alligments.
This error message is specific to stm32.
Did you look at the stm32 source code?
Are you *sure* the error message isn't in fact telling you that this is a quaint
requirement of stm32?
Warn : 225 1129 stm32x.c:366 stm32x_protect(): Error: start and end
sectors must be on a 4 sector boundary
There is a bug in stm32 code in that it gives you a warning and not
an error, but that's minor.
if ((first (first % stm32x_info-ppage_size)) || ((last + 1)
(last + 1) % stm32x_info-ppage_size))
{
LOG_WARNING(Error: start and end sectors must be on a %d sector
boundary, stm32x_info-ppage_size);
return ERROR_FLASH_SECTOR_INVALID;
}
--
Øyvind Harboe
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 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 1:56 AM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote: Checkout your branch and run 'git rebase master'. That will update your branch against the current master. Then, do the same thing with '-i'. Select the patches to change and mark them with 'e', change the files, add them and --amend the comment, then --continue the rebase. Rinse and repeat for all marked files. Great, that was easy, thanks! Here's an updated patch, this time using C99 variable length arrays. I'm using the unbounded string functions here, guessing we can trust getenv() to return a piece of memory that won't change on the fly. Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. -- Øyvind Harboe 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/2] support for scripts in $HOME/.openocd
Search for alloc_printf(). It is a printf which allocates the string dynamically. Remember to free it up after you had finished using it + add error checking and propagation. -- Øyvind Harboe 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] Document build broken when src != build
I can no longer build docs when src != build. I believe this is trivially reproducible and that the breakage is relatively recent(a month or so). Or... perhaps I'm missing some tool on my laptop? make docs make doxygen = both fail make doxygen/latex/refman.pdf make[1]: Entering directory `/home/oyvind/workspace/build' make[1]: *** No rule to make target `doxygen/latex/refman.pdf'. Stop. I saw this error warning fly by doxygen Doxyfile 21 | perl ../zy1000/openocd/tools/logger.pl doxygen.log Warning: tag INPUT: input source `../zy1000/openocd/config.h' does not exist Warning: source ../zy1000/openocd/config.h is not a readable file or directory... skipping. -- Øyvind Harboe 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 3/3] support for scripts in $HOME/.openocd
On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Do not use variable length arrays. Use malloc(). If you use variable length arrays on the stack that messes with embedded / uCLinux hosts. Only if the embedded host uses a home directory path longer than what will fit on the stack. Is this really a problem? /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Document build broken when src != build
On Sun, Nov 22, 2009 at 10:17 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I can no longer build docs when src != build. I believe this is trivially reproducible and that the breakage is relatively recent(a month or so). Or... perhaps I'm missing some tool on my laptop? make docs make doxygen = both fail make doxygen/latex/refman.pdf make[1]: Entering directory `/home/oyvind/workspace/build' make[1]: *** No rule to make target `doxygen/latex/refman.pdf'. Stop. I saw this error warning fly by doxygen Doxyfile 21 | perl ../zy1000/openocd/tools/logger.pl doxygen.log Warning: tag INPUT: input source `../zy1000/openocd/config.h' does not exist Warning: source ../zy1000/openocd/config.h is not a readable file or directory... skipping. Same problem here, automatic git bisect revealed 0091e59d2a18c293fd952a9d707e609afdd6b17f to be the culprit. The warning message is unrelated. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Document build broken when src != build
On Sunday 22 November 2009, Øyvind Harboe wrote: make[1]: *** No rule to make target `doxygen/latex/refman.pdf'. Stop. Similar happens with src == build... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] v0.3.2 branch at oharboe/v0.3.2
I need to backport some embedded/uClinux/pthread(?) stack overflow fixes from the sf master branch. I'll be maintaining a branch at oharboe/v0.3.2 and possibly pushing this to sf if there is any interest/once it has settled down. No problems affecting operating systems w/automatic stack expansion have been found yet. *nix/Windows/Mac are not affected to my knowledge. uClinux would be affected. -- Øyvind Harboe 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: flash write_image has an alignment issue and flash protect/erase is broken
Øyvind Harboe wrote:
Maybe the following example (output is pasted below) can illustrate the issue
a bit better. First I try to flash a 20KB block, then a 21KB block and
finally a 24KB block. Only the blocks of 20 and 24 succeed, because they
happen
to be nicely 4K alligned. All blocks that are not 4K alligned will fail.
OpenOCD
tries to erase, (un)protect and flash only those sectors that are modified,
but doesn't take into account that some platforms require certain alligments.
This error message is specific to stm32.
Did you look at the stm32 source code?
Yes, I know that code. I've got a committed patch of mine in there.
Are you *sure* the error message isn't in fact telling you that this is a
quaint
requirement of stm32?
It most certainly an STM32 specific quirk. This is sort of what I was trying to
say in the first place. Let met explain further:
* The flash write_image function is trying to be smart by only deleting,
(un)protecting and flashing those sectors that have to be modified. This is a
good thing.
* The STM32 specific flash code has certain alignment requirements, which
currently only generate an error in case of a non-compliant situation. This is
not very bad, but it can be done better.
* My suggestion is to add a global parameter which tells OpenOCD to handle
alignment issues in a smart way (globally); by adjusting the sector counts
automatically in such that these errors do not appear. I suggest that we do not
make this the default setting, because the flash write_image and flash
write_sectors use the same code to write to the flash. If the default settings
are such that OpenOCD automatically adjusts sector counts, then the user might
get unexpected results when using flash write_sectors. So to be safe, OpenOCD
must not adjust sector counts, but only when told to do so.
* For now, the smart_sector_aligment setting will only be regarded by the
STM32-specific code. Any other platforms that are eligible for alligment
smartness? A quick grep through the code gives:
./src/flash/lpc288x.c:320: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/lpc2000.c:568: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/stellaris.c:946:return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/stm32x.c:572: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str9xpec.c:589: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/pic32mx.c:482: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/at91sam7.c:975: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/avrf.c:229: return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str9x.c:481:return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
./src/flash/str7x.c:449:return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
So, I'll try and figure out where smart_aligment might be useful. As these are
quite a diverse bunch of controllers, I'm not sure I dare touch all of the
code. I'll have to see if it's worth the trouble, if at all do-able.
There is a bug in stm32 code in that it gives you a warning and not
an error, but that's minor.
if ((first (first % stm32x_info-ppage_size)) || ((last + 1)
(last + 1) % stm32x_info-ppage_size))
{
LOG_WARNING(Error: start and end sectors must be on a %d sector
boundary, stm32x_info-ppage_size);
return ERROR_FLASH_SECTOR_INVALID;
}
Correct. And I will remove this little beauty mark along with adding the
alignment parameter then :-)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32: flash write_image has an alignment issue and flash protect/erase is broken
Clearly you know more about this problem than I intend to learn about it :-) Would it be possible to consider a change in the flash driver model that would allow the drivers to just deal with it? I'm loathe to add obscure and hard to grasp options... flash write_image unlock erase xxx should just work dammit with no funny options. -- Øyvind Harboe 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: flash write_image has an alignment issue and flash protect/erase is broken
Perhaps more of flash write_image needs to be pushed into the flash drivers to give the flash drivers enough context? Some new fn call in the driver with a default implementation? -- Øyvind Harboe 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] Allocate working storage dynamically
David Brownell identified a few more important sites of non-trivial
amounts of working memory allocated on stack.
Change to dynamic allocation.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From aacc5b583c6415fe8d3e6fc99066d6ef819fa22c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?= oyvind.har...@zylin.com
Date: Sun, 22 Nov 2009 18:58:42 +0100
Subject: [PATCH 1/2] target: reduce stack usage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
4096 byte buffer allocated dynamically. Better
for embedded OS's.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/target/target.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/src/target/target.c b/src/target/target.c
index 70fd8f2..55adcce 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -3145,7 +3145,6 @@ static int target_mem2array(Jim_Interp *interp, struct target *target, int argc,
uint32_t count;
uint32_t v;
const char *varname;
- uint8_t buffer[4096];
int n, e, retval;
uint32_t i;
@@ -3227,14 +3226,20 @@ static int target_mem2array(Jim_Interp *interp, struct target *target, int argc,
/* index counter */
n = 0;
+
+ size_t buffersize = 4096;
+ uint8_t *buffer = malloc(buffersize);
+ if (buffer == NULL)
+ return JIM_ERR;
+
/* assume ok */
e = JIM_OK;
while (len) {
/* Slurp... in buffer size chunks */
count = len; /* in objects.. */
- if (count (sizeof(buffer)/width)) {
- count = (sizeof(buffer)/width);
+ if (count (buffersize/width)) {
+ count = (buffersize/width);
}
retval = target_read_memory(target, addr, width, count, buffer);
@@ -3268,6 +3273,8 @@ static int target_mem2array(Jim_Interp *interp, struct target *target, int argc,
}
}
+ free(buffer);
+
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
return JIM_OK;
@@ -3331,7 +3338,6 @@ static int target_array2mem(Jim_Interp *interp, struct target *target, int argc,
uint32_t count;
uint32_t v;
const char *varname;
- uint8_t buffer[4096];
int n, e, retval;
uint32_t i;
@@ -3415,12 +3421,18 @@ static int target_array2mem(Jim_Interp *interp, struct target *target, int argc,
n = 0;
/* assume ok */
e = JIM_OK;
+
+ size_t buffersize = 4096;
+ uint8_t *buffer = malloc(buffersize);
+ if (buffer == NULL)
+ return JIM_ERR;
+
while (len) {
/* Slurp... in buffer size chunks */
count = len; /* in objects.. */
- if (count (sizeof(buffer)/width)) {
- count = (sizeof(buffer)/width);
+ if (count (buffersize/width)) {
+ count = (buffersize/width);
}
v = 0; /* shut up gcc */
@@ -3454,6 +3466,8 @@ static int target_array2mem(Jim_Interp *interp, struct target *target, int argc,
}
}
+ free(buffer);
+
Jim_SetResult(interp, Jim_NewEmptyStringObj(interp));
return JIM_OK;
--
1.6.3.3
From 0c4016941da7aa32719704a790ab66c5a2c53f30 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?= oyvind.har...@zylin.com
Date: Sun, 22 Nov 2009 19:06:44 +0100
Subject: [PATCH 2/2] flash: dynamically allocate working storage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Allocate working memory rather than using stack.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/flash/flash.c | 50 --
1 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/src/flash/flash.c b/src/flash/flash.c
index ef6c6da..b65ce0a 100644
--- a/src/flash/flash.c
+++ b/src/flash/flash.c
@@ -728,24 +728,40 @@ COMMAND_HANDLER(handle_flash_fill_command)
uint32_t address;
uint32_t pattern;
uint32_t count;
- uint8_t chunk[1024];
- uint8_t readback[1024];
uint32_t wrote = 0;
uint32_t cur_size = 0;
uint32_t chunk_count;
struct target *target = get_current_target(CMD_CTX);
uint32_t i;
uint32_t wordsize;
+ int retval = ERROR_OK;
+
+ static size_t const chunksize = 1024;
+ uint8_t *chunk = malloc(chunksize);
+ if (chunk == NULL)
+ return ERROR_FAIL;
+
+ uint8_t *readback = malloc(chunksize);
+ if (readback == NULL)
+ {
+ free(chunk);
+ return ERROR_FAIL;
+ }
+
if (CMD_ARGC != 3)
- return ERROR_COMMAND_SYNTAX_ERROR;
+ {
+ retval = ERROR_COMMAND_SYNTAX_ERROR;
+ goto done;
+ }
+
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[0], address);
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[1], pattern);
COMMAND_PARSE_NUMBER(u32, CMD_ARGV[2], count);
if (count == 0)
- return ERROR_OK;
+ goto done;
switch (CMD_NAME[4])
{
@@ -759,7 +775,8 @@ COMMAND_HANDLER(handle_flash_fill_command)
wordsize = 1;
break;
default:
- return ERROR_COMMAND_SYNTAX_ERROR;
+ retval = ERROR_COMMAND_SYNTAX_ERROR;
+ goto done;
}
chunk_count = MIN(count, (1024 / wordsize));
@@ -795,15 +812,22 @@ COMMAND_HANDLER(handle_flash_fill_command)
bank = get_flash_bank_by_addr(target, address);
if (bank == NULL)
{
- return ERROR_FAIL;
+
Re: [Openocd-development] Allocate working storage dynamically
On Sunday 22 November 2009, Øyvind Harboe wrote: David Brownell identified a few more important sites of non-trivial amounts of working memory allocated on stack. Correction: linux/scripts/checkstack.pl did that for us. ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32: flash write_image has an alignment issue and flash protect/erase is broken
Øyvind Harboe wrote: Perhaps more of flash write_image needs to be pushed into the flash drivers to give the flash drivers enough context? Some new fn call in the driver with a default implementation? That was my first thought. But then I thought that that would affect all drivers, so I liked the thought of a quick and simple solution like a 'just_shutup_and_work' flag. But I'm afraid that your proposal might be the way to go. I need to take a better look at the rest of the code to get a better picture first. I'll try and have a look this week and see what will be the most future-proof sollution. (Crap. Me and my big mouth :-) Cheers, Johnny ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd vrs Commercial jtag dongles
David Brownell wrote: On Saturday 21 November 2009, Duane Ellis wrote: It is just blindingly fast... I suspect that many of those speed improvements can be had even with a CPU-based solution ... ... Consider a board: USB -- Cortex-M3 -- level shifting -- JTAG ... Come up with such a board with initial it works firmware ... and OpenOCD could speed things up over time. Now there's an interesting project. Do I hear a call for porting OpenOCD to an STM32 (got USB) + $some_rtos system? Now that's got to be fast. It shouldn't even be that hard I think. Most of the code is already at hand, I suspect. GDB for the interface, JTAG code for, well, JTAG stuff. Take current OpenOCD, maybe chuck in an OS (FreeRTOS, ChibiOS, eCos) , or not, and add some control code, and some commandline code and you should be a long way towards a working system. And if no custom board is available yet, you can just by one of those cheap Olimex header boards and and a small leveshifter circuit, which is real easy to build, and voila. Later on then, a cleaner, custom circuit can be designed, with integrated level shifters and such. Shouldn't be that expensive. Not that I even remotely have the time to do any of this, but still, it is an entertaining thought. Johnny ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OOCD V0.x.y doesn't work with STM32 low density devices?
No, i tried alot of clock combinations from 1kHz to 1MHz, the clock is not the issue, i think. The electrical signals a very good (measured witz oscilloscop). I also tried to clock the target with 5MHz (with the PEEDI) and it works well. christian Original-Nachricht Datum: Thu, 19 Nov 2009 14:38:36 -0700 Von: David Brownell davi...@pacbell.net An: openocd-development@lists.berlios.de CC: Christian Dumhart christian.dumh...@gmx.at Betreff: Re: [Openocd-development] OOCD V0.x.y doesn\'t work with STM32 low density devices? On Thursday 19 November 2009, Christian Dumhart wrote: I've tried alot to bring up my board with the OOCD and Olimex JTAG, but it doesn't work. Can somebody explane the problem and help me to solve it? My first reaction was that this looks like your JTAG clock is too fast ... since a number of the bit patterns show your values are shifted by a bit or two from what they should be. Once you get the clocking right, it'll work better. How fast are you clocking the STM32? -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] What became of the generic LPC config script?
I can't seem to find the generic LPC config script work that was done(but never committed). What was the story on why it wasn't committed yet? -- Øyvind Harboe 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
