On 11/11/2010 23:26, Peter Stuge wrote:
Freddie Chopin wrote:
according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a lot of
experience that is valuable.
The
On 12/11/2010 10:33, Spencer Oliver wrote:
On 11/11/2010 23:26, Peter Stuge wrote:
Freddie Chopin wrote:
according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a
On 2010-11-12 12:16, Spencer Oliver wrote:
Mmm - Think i may be incorrect here, the cortex_m3 reset_config does
override the standard reset_config.
Looking back this was done so it did not break any stellaris scripts
that define reset config.
Would that be enough to change behavior so that
--- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote:
it's hard to imagine a chip that has no srst,
As for boards or JTAG adapters without nSRST,
no imagination is required; I have production
boards of both flavors.
that option can be removed
Shouldn't be, though; that'd be
David Brownell wrote:
--- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote:
it's hard to imagine a chip that has no srst,
As for boards or JTAG adapters without nSRST,
no imagination is required; I have production
boards of both flavors.
Very true, but I think part of the
On 2010-11-12 18:27, Peter Stuge wrote:
David Brownell wrote:
As for boards or JTAG adapters without nSRST,
no imagination is required; I have production
boards of both flavors.
Show my an example of any _normal_ JTAG interface that does not have
srst? As for the second case, OpenOCD's main
Freddie Chopin wrote:
On 2010-11-12 18:27, Peter Stuge wrote:
David Brownell wrote:
As for boards or JTAG adapters without nSRST,
no imagination is required; I have production
boards of both flavors.
Show my an example of any _normal_ JTAG interface that does not have
srst?
I'm sure there
Show my an example of any _normal_ JTAG interface that does
not have srst?
Depends entirely on what you mean by normal,
doesn't it? All I can say is that I've come across non-prototype boards that
don't rely
on that signal, and thus don't provide JTAG
support for it. That is, boards
On 11/12/2010 06:40 PM, Freddie Chopin wrote:
Show my an example of any _normal_ JTAG interface that does not have
srst? As for the second case, OpenOCD's main purpose is debugging, not
programming, so production boards are not very interesting here.
At least the Xilinx JTAG cables have no
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell davi...@pacbell.net wrote:
Today I've noticed that resetting the chip
with OpenOCD does NOT reset
peripheals (the chip is STM32F103RBT8), which
IMO is not very good...
Not all SoCs reset peripherals like that; don't
assume they do.
--- On Thu, 11/11/10, Andreas Fritiofson andreas.fritiof...@gmail.com wrote:
It's not an assumption, it's in the manual. Do you have an example of
a microcontroller which doesn't reset the bulk of the peripherals on a NRST
or equivalent?
Not handy, no; it surprised me too. ISTR there
was
On 11/11/2010 05:01, Peter Stuge wrote:
Spencer Oliver wrote:
The default behaviour was changed to make it compatible with all
cortex-m3 cores - will have to check but some stm32 and nxp parts
had issues using SYSTEMRESET.
Please give more detail about those nxp parts?
All LPC17xx devices
Hi!
I've thought about that whole patch which adds cortex-m3 reset_config
command and I think it's not very good now (if I correctly understand
its behavior).
Let's say, that there is a chip which has some problems with
SYSRESETREQ, so the target config file forces VECTRESET (which is not a
Freddie Chopin wrote:
according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a lot of
experience that is valuable.
The policy stuff is nonsense. If there is a
On 2010-11-12 00:26, Peter Stuge wrote:
Freddie Chopin wrote:
according to OpenOCD (brilliant) policy of target config files
I think it would be great if you stopped complaining using sarcasm
and instead help analyze and improve. I think you have a lot of
experience that is valuable.
The
Hi!
I've doubts about this commit
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5
Today I've noticed that resetting the chip with OpenOCD does NOT reset
peripheals (the chip is STM32F103RBT8), which IMO is not very good...
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote:
Hi!
I've doubts about this commit
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5
Today I've noticed that resetting the chip with OpenOCD does
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote:
Hi!
I've doubts about this commit
On 10/11/2010 19:01, Andreas Fritiofson wrote:
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopinfreddie_cho...@op.pl wrote:
Hi!
I've doubts about this commit
The default behaviour was changed to make it compatible with all cortex-m3
cores - will have to check but some stm32 and nxp parts had issues using
SYSTEMRESET.
I think it would be good for openocd to have knowledge of what core can
handle certain reset modes.
We have already gone down this
On Wed, Nov 10, 2010 at 10:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Spencer Oliver s...@spen-soft.co.uk wrote:
The default behaviour was changed to make it compatible with all cortex-m3
cores - will have to check but some stm32 and nxp parts had issues using
SYSTEMRESET.
I believe
Today I've noticed that resetting the chip
with OpenOCD does NOT reset
peripheals (the chip is STM32F103RBT8), which
IMO is not very good...
Not all SoCs reset peripherals like that; don't
assume they do. Likewise, not all boards.
- Dave
___
Spencer Oliver wrote:
The default behaviour was changed to make it compatible with all
cortex-m3 cores - will have to check but some stm32 and nxp parts
had issues using SYSTEMRESET.
Please give more detail about those nxp parts?
//Peter
___
23 matches
Mail list logo
