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 re
>
> 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
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?
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 p
David Brownell wrote:
> --- On Fri, 11/12/10, Freddie Chopin 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 current confusion i
--- On Fri, 11/12/10, Freddie Chopin 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 very unwise.
- Dave
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 har
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 l
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 "pol
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 "pol
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 comp
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
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
--- On Thu, 11/11/10, Andreas Fritiofson 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 a register controlling th
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell 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. Likewise
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
___
Open
> >>> 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
__
On Wed, Nov 10, 2010 at 10:15 PM, Øyvind Harboe 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.
I believe STM32 does what it is supposed to, I'
> 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
On 10/11/2010 19:01, Andreas Fritiofson wrote:
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
wrote:
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin wrote:
Hi!
I've doubts about this commit
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df064
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson
wrote:
> On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin 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 n
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin 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 NOT reset
> periph
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...
23 matches
Mail list logo
