Hi Freddie,
after being slapped in the face by the error, try manually entering the
following:
cd src
x86_64-w64-mingw32-gcc -std=gnu99 -g -O2 -D__USE_MINGW_ANSI_STDIO
-I/home/freddie/Pobrane/ftd2xx -Wall -Wstrict-prototypes -Wformat-security
-Wextra -Wno-unused-parameter -Wbad-function-cast
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
>
...
> C
Ø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, s
Ø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 bl
Hi,
Øyvind Harboe wrote:
>
> Could you include a debug_level 3 trace?
>
> The conclusion seems a bit premature based on the limited information
> above.
>
>
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
Hiya,
I've found a few issues in OpenOCD and thought that I'd share before hacking a
solution together. The following revision is used:
commit 8f446fcf676e9cd13cf53d9946f0cae5d29a10ec
Date: Thu Nov 19 13:23:49 2009 -0800
When doing "flash write_image erase unlock image.bin 0x800 bin" on a
Hi Colin,
top of the bill, as far as I know, is IDA pro. Simply amazing product, with
matching pricetag. Google-ing for 'arm disassembler' will ofcourse yield some
more results.
http://www.hex-rays.com/idapro/
Cheers,
Johnny
Colin Howarth wrote:
> Hello all,
>
> I'm not entirely sure this i
David Brownell wrote:
> On Sunday 20 September 2009, Johnny Halfmoon wrote:
>> + if ((retval = flash_check_sector_parameters(cmd_ctx, first,
>> last, p->num_sectors)) !
>
> I had in mind more like
>
> uint32_t value;
Okay. Like this then:
Fair enough. Try this then (with some added parameter checking)...
= = =
doc/openocd.texi |6 --
src/flash/flash.c | 47 ---
2 files changed, 48 insertions(+), 5 deletions(-)
Index: src/flash/flash.c
===
David Brownell wrote:
>>
>
> Doesn't build:
> stm32x.c: In function ‘stm32x_protect’:
> stm32x.c:413: warning: too few arguments for format
>
> You need to compute that multiple. :)
>
> Suggest you avoid such a LONG message in any case.
> Better: "Invalid sector start/end; must b
This patch modifies an error message which, in its original state, I find
somewhat unhelpful. So a small hint was added.
Signed-off-by: Johnny Halfmoon
---
stm32x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: trunk/src/flash/stm32x.c
This patch slightly enhances the behaviour of the standard erase and protect
functions. After applying this patch, defining -1 as the last sector tells
OpenOCD to protect or erase the entire flash bank. The relevant part in the
OpenOCD has been updated.
Signed-off-by: Johnny Halfmoon
12 matches
Mail list logo