On 17.12.2009 19:39, David Brownell wrote:
> On Thursday 17 December 2009, Dirk Behme wrote:
>
>> Ok, after board reset I get
>>
>> -- cut --
>> > scan_chain
>> TapName Enabled IdCode Expected IrLen IrCap IrMask
>> -- --- -- -- ---
Read-modify-erase-write on per-sector basis?
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of David Brownell
> Sent: Tuesday, December 22, 2009 8:23 PM
> To: Øyvind Harboe
> Cc: openocd-developme
On Tuesday 22 December 2009, Freddie Chopin wrote:
> >> flash write_image erase c:\\a.hex
> > auto erase enabled
> > address range 0x0800 .. 0x0800681b is not sector-aligned
> > Command handler execution failed
> > in procedure 'flash' called at file "command.c", line 637
> > called at file "co
On Tuesday 22 December 2009, Øyvind Harboe wrote:
> This is a bit worse than I thought.
>
> This breaks flash write_image as well.
That was *this* problem report, in fact...
> Flash write_image will first erase all sectors in address ranges of
> all segments to be written, then it will write al
On Tuesday 22 December 2009, Yegor Yefremov wrote:
> After applying the latest patches 0.4-rc1 I encountered the following error:
>
> halt
> flash write_image erase image.bin 0x1000 bin
> auto erase enabled
> address range 0x1000 .. 0x000135d3 is not sector-aligned
> Command handler execution
Ignore this for now. It runs fine with -O0, segfaults with -O2. Now to figure
out why.
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Austin, Alex
> Sent: Tuesday, December 22, 2009 4:45 PM
>
This is a known problem.
revert nor/flash/core.c to 5fdee60fd4d38e59c7b5f7aca5ad50b90e7d61ee
and see if it doesn't fix it.
--
Ø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 programm
When trying to flash STM32:
>> flash write_image erase c:\\a.hex
> auto erase enabled
> address range 0x0800 .. 0x0800681b is not sector-aligned
> Command handler execution failed
> in procedure 'flash' called at file "command.c", line 637
> called at file "command.c", line 352
Don't know wha
When building standard configuration on Windows (MSYS + MinGW):
> libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src
> -I../../src -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes
> -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
> -Wcast-alig
When building standard configuration on Windows (MSYS + MinGW):
> libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src
> -I../../src -g -O2 -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes
> -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
> -Wcast-alig
Ouch.
This is a bit worse than I thought.
This breaks flash write_image as well.
Flash write_image will first erase all sectors in address ranges of
all segments to be written, then it will write all segments.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http:
An alternative would be to add an option that is disabled by
default that will check that the address range matches sector
boundaries. This is incompatible, but perhaps a better way to
go?
This would be along the lines of the options we have for flash
write_image.
flash erase_address force =
On Tue, Dec 22, 2009 at 3:47 PM, Yegor Yefremov
wrote:
> On Fri, Dec 18, 2009 at 12:49 AM, David Brownell wrote:
>> Much to my surprise, I observed a "flash erase_address ..."
>> command erasing data which I didn't say should be erased.
>>
>> The issue turns out to be generic NOR flash code which
On Fri, Dec 18, 2009 at 12:49 AM, David Brownell wrote:
> Much to my surprise, I observed a "flash erase_address ..."
> command erasing data which I didn't say should be erased.
>
> The issue turns out to be generic NOR flash code which was
> silently, and rather dangerously, morphing partial-sect
Give hardware breakpoints a go.
(gdb) hbreak *0x2314
--
Ø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
Hello, all.
A program, before it can run at it's runtime address, it has to configure the
memory, copy itself to the memory,
or enable the MMU; after these, it can run at it's runtime address.
My question is, how can I debug it with OpenOCD and gdb, when it does not
run at it's runtime addre
16 matches
Mail list logo
