On Tue, Nov 10, 2009 at 6:32 PM, Freddie Chopin wrote:
> Øyvind Harboe pisze:
>>
>> You mean that "reset_config" should ignore any previous invocations
>> of "reset_config", right?
>
> Exactly, moreover - if that's not out of sense for particular case - other
> commands could follow: jtag_speed, j
Øyvind Harboe pisze:
> You mean that "reset_config" should ignore any previous invocations
> of "reset_config", right?
Exactly, moreover - if that's not out of sense for particular case -
other commands could follow: jtag_speed, jtag_khz (this two already do),
jtag_xxx_delay, work areas, flash b
David Brownell pisze:
> That's only barely plausible with certain microcontrollers, which
> aren't very configurable. For more complex boards, it's unworkable.
True - there are chips that need a lot of configuration, but is OpenOCD
aiming for such chips and their users only? For me that's a GREA
On Tuesday 10 November 2009, Thomas Kindler wrote:
> Out of curiosity, I've hooked SRST and TRST up to an oscilloscope. See
> attachments for "reset" using different reset_configs (SRST on top, TRST
> on bottom. Notice time base settings)
>
> The ones with SRST clearly show the double system-res
> > Said differently: STM32 can use the current Cortex-M3 NVIC reset
> > logic with no problems. Good to know.
>
> Nice!
Agreed. :)
> At least the "high-density device limitations" for my STM32F103VE
> deosn't seem to list any reset problems:
>
>http://www.st.com/stonline/products/lite
On Monday 09 November 2009, Freddie Chopin wrote:
> David Brownell pisze:
> > The stm32.cfg shouldn't specify a reset type at all, since
> > the right configuration depends on what the *board* wires up.
> > Send a patch in ... :)
>
> I think this policy should be changed... IMHO all /board and /ta
On Tue, Nov 10, 2009 at 7:27 AM, Freddie Chopin wrote:
> David Brownell pisze:
>> The stm32.cfg shouldn't specify a reset type at all, since
>> the right configuration depends on what the *board* wires up.
>> Send a patch in ... :)
>
> I think this policy should be changed... IMHO all /board and /
David Brownell pisze:
> The stm32.cfg shouldn't specify a reset type at all, since
> the right configuration depends on what the *board* wires up.
> Send a patch in ... :)
I think this policy should be changed... IMHO all /board and /target
should be merged and the problem would be gone.
Another
David Brownell wrote:
>> Back to your question: I tried all of the four signal options, and
>> /basically/ all of them work. I can attach log files if needed.
>>
>> "none" and "trst_only" seem to be the best options -- only one reset,
>> or reset-and-immediate-halt, as expected.
>
> Said differen
On Monday 09 November 2009, Thomas Kindler wrote:
> David Brownell wrote:
> >> Even "reset halt" will let the CPU run for some amount of time
> >> (e.g. enough to print a Hello-World string to the serial port..).
> >
> > Now *that* is a bug. And one that I suspect is specific to STM32, or
> > at
David Brownell wrote:
>> Even "reset halt" will let the CPU run for some amount of time
>> (e.g. enough to print a Hello-World string to the serial port..).
>
> Now *that* is a bug. And one that I suspect is specific to STM32, or
> at least to your particular chip, since I've not observed it on
On Monday 09 November 2009, Thomas Kindler wrote:
> Using an Amontec JTAGkey-Tiny and STM32 (on cygwin), every time I do an
> "reset", the chip actually resets twice.
>
> The problem exists since I first used OpenOCD (< 0.1.0).
And it's not specific to that hardware. You can see what
causes it
Using an Amontec JTAGkey-Tiny and STM32 (on cygwin), every time I do an
"reset", the chip actually resets twice.
The problem exists since I first used OpenOCD (< 0.1.0).
Even "reset halt" will let the CPU run for some amount of time (e.g.
enough to print a Hello-World string to the serial port
13 matches
Mail list logo
