David Brownell a écrit :
On Monday 11 January 2010, Michel Catudal wrote:
That is correct. As for the watchdog, once you enable it you can no
longer debug as it keep reseting.
Isn't there an STM32-specific register to prevent the watchdog
from counting while the core
On Monday 11 January 2010, Michel Catudal wrote:
> That problem has existed as long as I can remember. I have seen no
> improvement in the latest versions.
> Since no one seemed to have that problem, Like Freddie I assumed the problem
> was with me.
> It has never worked correctly so I can't g
On Monday 11 January 2010, Michel Catudal wrote:
> define hook-step
> mon cortex_m3 maskisr on
> end
> define hookpost-step
> mon cortex_m3 maskisr off
> end
>
> What calls these hooks? gdb?
Yes.
___
Openocd-development mailing list
Openocd-deve
On Monday 11 January 2010, Michel Catudal wrote:
> That is correct. As for the watchdog, once you enable it you can no
> longer debug as it keep reseting.
Isn't there an STM32-specific register to prevent the watchdog
from counting while the core is in debug halt state?
That's the solution I'm
David Brownell a écrit :
On Sunday 10 January 2010, Michel Catudal wrote:
I still have a problem with STM32 where the first load doesn't work.
I don't remember seeing a description of such an issue ... can
you post one, or an URL to a description in the mailing list?
W
There is a new development on the libusb 1.0 for Windows front now that
libusb 1.0 already works under Linux and Mac OS X. Now the libusb-winusb
branch reached beta status. This may be a good alternative to the libusb-win32
project which has not moved for years.
http://old.nabble.com/libusb-1.0-fo
On Monday 11 January 2010, Thomas Kindler wrote:
> Joseph Yiu suggested this code to cause a hard-fault:
>
> __asm(
> "movs r0, #1 \t\n" // unaligned ..
> "ldm r0, {r1-r2} \t\n" // .. load-multiple
> "bx lr \t\n"
> );
>
> (see http://www.st.com/mcu/for
> "David" == David Brownell writes:
Hi,
>> doc/openocd.texi | 3 ++-
>> src/flash/nand/Makefile.am | 1 +
>> src/flash/nand/driver.c | 2 ++
>> src/flash/nand/{s3c2443.c => s3c6400.c} | 28
Davi
On Monday 11 January 2010, Peter Korsgaard wrote:
> Identical to the existing 2412/2443 support except for the base address
> and NFCONF value (bit 2 is reserved and should be written as 1 ref UM).
>
> Tested on a s3c6410 board, but controller is identical in 6400/6410
> except for 8bit MLC ECC su
Identical to the existing 2412/2443 support except for the base address
and NFCONF value (bit 2 is reserved and should be written as 1 ref UM).
Tested on a s3c6410 board, but controller is identical in 6400/6410
except for 8bit MLC ECC support in 6410 which isn't supported by the
driver.
Signed-o
On Monday 11 January 2010, Edgar Grimberg wrote:
> I'm doing target tests according to a test plan. I want to test the
> basic functionality of OpenOCD:
Test Plan? That sounds ... pleasantly organized!! :)
> * Connectivity: telnet, GDB
> * Reset, using the provided configuration scripts, on ta
Fixed the flash_config registered name. Tested on a HITEX STR912 evalboard.
Signed-off-by: Edgar Grimberg
---
src/flash/nor/str9x.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index 9cddb50..75c8152 100644
--- a/src/flas
On Mon, Jan 11, 2010 at 4:44 PM, David Brownell wrote:
> On Monday 11 January 2010, Edgar Grimberg wrote:
>> index 9cddb50..75c8152 100644
>> --- a/src/flash/nor/str9x.c
>> +++ b/src/flash/nor/str9x.c
>> @@ -679,7 +679,7 @@ COMMAND_HANDLER(str9x_handle_flash_config_command)
>>
>> static const str
David Brownell wrote:
>>> If that's part of the issue, you might be able to
>>> work around it by updating DEMCR before shutting
>>> down. "cortex_m3 vector_catch none" maybe.
>> Well, it helps a bit. Adding "CoreDebug->DEMCR = 0;" to the start of my
>> program does the same.
>
> To clarify: it
On Monday 11 January 2010, Edgar Grimberg wrote:
> index 9cddb50..75c8152 100644
> --- a/src/flash/nor/str9x.c
> +++ b/src/flash/nor/str9x.c
> @@ -679,7 +679,7 @@ COMMAND_HANDLER(str9x_handle_flash_config_command)
>
> static const struct command_registration str9x_config_command_handlers[] = {
>
Fixed the flash_config registered name. Tested on a HITEX STR912 evalboard.
Signed-off-by: Edgar Grimberg
---
src/flash/nor/str9x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/flash/nor/str9x.c b/src/flash/nor/str9x.c
index 9cddb50..75c8152 100644
--- a/src/flas
On Monday 11 January 2010, Thomas Kindler wrote:
> David Brownell wrote:
> > On Monday 11 January 2010, Thomas Kindler wrote:
> >> How could this be fixed or explained?
> >
> > There's some curious voodoo in the Cortex-M3 code
> > where it mucks with fault handling ... see in the
> > cortex_m3_end
Pushed.
Thanks!
--
Ø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@list
one line / command instead of one line per argument.
Signed-off-by: Øyvind Harboe
---
src/helper/command.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/helper/command.c b/src/helper/command.c
index cf66f8a..84d687d 100644
--- a/src/helper/command.c
+++ b/sr
From: Vladimir Zapolskiy
Added interface config file for JTAG/RS232 debug board originally
integrated to Neo 1973 and Neo FreeRunner phones.
Adapter was tested with i.MX31, S3C2410 and AT91SAM9260 processors.
Signed-off-by: Vladimir Zapolskiy
---
tcl/interface/neodb.cfg | 10 ++
1 fi
Signed-off-by: Øyvind Harboe
---
src/target/arm720t.c |1 +
src/target/arm7tdmi.c |1 +
src/target/arm920t.c |1 +
src/target/arm926ejs.c |1 +
src/target/arm966e.c |1 +
src/target/arm9tdmi.c |1 +
src/target/fa526.c |1 +
7 files changed, 7 insertions(+),
Allow targets to run checks post reset. Used to check
that e.g. DCC downloads have been enabled.
Signed-off-by: Øyvind Harboe
---
src/target/target.c | 14 ++
src/target/target_type.h |7 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/target/ta
DCC downloads should be enabled for any self repecting
openocd config file for arm7/9. Print out note about
it otherwise.
Signed-off-by: Øyvind Harboe
---
src/target/arm7_9_common.c | 11 +++
src/target/arm7_9_common.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff -
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>> How could this be fixed or explained?
>
> There's some curious voodoo in the Cortex-M3 code
> where it mucks with fault handling ... see in the
> cortex_m3_endreset_event() routine where it sets
> up to trap some faults au
On Monday 11 January 2010, Thomas Kindler wrote:
> How could this be fixed or explained?
There's some curious voodoo in the Cortex-M3 code
where it mucks with fault handling ... see in the
cortex_m3_endreset_event() routine where it sets
up to trap some faults automagically. REVISIT
comments mark
startup.tcl was split into one startup.tcl / module, which is nice.
However, this improvement made stack traces harder to read
as '"embedded:startup.tcl", line N' is now ambiguous.
Now if startup.tcl was just published together with the rest
of OpenOCD as any other script, that wouldn't be a prob
I'm working on stm32 and found that the jim error messages could be
more helpful in pointing towards the location of the problem.
I'm not very confident in the attached code, change, but have a look
at the result below, notice how the line #'s in the tcl files show up.
Before:
> reset init
JTA
Hi!
I just encountered a strange problem on my STM32F103 board.. I've
written a very simple hard fault handler that sets a LED output and
loops forever.
Everything works fine after initial power on. I can trigger a fault with
an unaligned load multiple operation and the handler will get cal
Take #3. Fix some warnings.
--
Ø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
From 682beb8ca5506a8fdb3b89fc227942bdee51a6d1 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98
On Mon, Jan 11, 2010 at 10:04 AM, David Brownell wrote:
> On Monday 11 January 2010, Øyvind Harboe wrote:
>> > Maybe if you passed wp_type not bp_type ... ?
>>
>> Thanks. Fixed. I meant well. :-)
>
> Looks right now. ;)
I'll await test results. I haven't tried it.
--
Øyvind Harboe
US toll fre
On Monday 11 January 2010, Øyvind Harboe wrote:
> > Maybe if you passed wp_type not bp_type ... ?
>
> Thanks. Fixed. I meant well. :-)
Looks right now. ;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios
> If that enumeration is defined by GDB protocol, it should not be placed
> in target.h - doing so is a layering violation which leads to errors
> just like this one.
It isn't. What happens in gdb_server.c is that there is a switch
statement to convert from GDB enum to OpenOCD enum. This is
a clea
On Mon, Jan 11, 2010 at 9:27 AM, David Brownell wrote:
> On Monday 11 January 2010, Øyvind Harboe wrote:
>> How's this patch?
>
> Maybe if you passed wp_type not bp_type ... ?
Thanks. Fixed. I meant well. :-)
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http:/
Jerry Ling wrote:
> There is a bug when using gdb to set read/write watchpoint.
> OOCD will actually set a "write" watchpoint if you set "read" watchpoint
> through gdb, and vis versa.
>
> Since...
> [target/breakpoints.h]
> enum watchpoint_rw
> {
> WPT_READ = 0, WPT_WRITE = 1, WPT_ACCESS = 2
On Monday 11 January 2010, Øyvind Harboe wrote:
> How's this patch?
Maybe if you passed wp_type not bp_type ... ?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Sunday 10 January 2010, Jerry Ling wrote:
> ... watchpoint_add(target, address, size, type-2, 0, 0xu) ...
Yeah, why isn't it passing "wp_type", which was already set
up with the right enum value? It does the right thing for
setting breakpoints, just a couple lines before. Sigh.
Doin
How's this patch?
--
Ø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
From ac931e8a3bd7fa6bb4434d0cb58a0a55d2fd3507 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20
37 matches
Mail list logo
