On Friday 25 September 2009, David Brownell wrote:
> Still chasing down why two ARM926 based boards don't reset right;
> those are a regressions. I've got a bit of progress; patches that
> switch from "OpenOCD startup works but 'reset' fails" over to the
> other way around. There's a clue in ther
Update FT2232 driver so that it reliably enters TAP_RESET.
When the OpenOCD server starts up it records its state as TAP_RESET,
even though it could be anything. Then when it starts to examine
the scan chain, it calls jtag_add_tlr() which sees it doesn't have
any work to do, and so it does nothin
On Saturday 26 September 2009, Freddie Chopin wrote:
> > A "wrapper" is already required to associate the right JTAG adapter
> > with the right target. I fail to see how adding the "set" in this:
> >
> > source [interface/...cfg]
> > set CRYSTAL_SPEED 3579545
> > source [target/...cfg
Streamline Capture-IR validation code
- Don't issue needless JTAG resets ... only do them after
errors. Normal exit now leaves every TAP in BYPASS.
- Fix an unlikely memory leak on one fault path.
- Remove the oddball limitation that invalid capture LSBs
trigger errors only for TAPs
Fix glitches in ARM11 command handling: commands were supposed
to have been "arm11 memwrite ..." not "memwrite ...".
Get rid of obfuscatory macros. Re-alphabetize.
Add docs for "arm11 vcr".
---
Someone with an ARM11 based board, please verify ... I've
got one but it's not currently set up.
do
David Brownell pisze:
> I don't see how that can be right either, except on chips that
> have a real way to halt-on-reset ... and as I understand, these
> chips from NXP don't support that. So chip startup code will run,
> and likely set up some clocking stuff first thing, which will be
> neither
On Saturday 26 September 2009, Freddie Chopin wrote:
> David Brownell pisze:
> > Not clear on the status of those LPC2xxx things. I think they'd
> > be ready to go if they didn't set up bogus clock rates...
>
> All I'm doing is waiting for your suggestion to solve the "bug" (for me
> that's not
On Wednesday 23 September 2009, Petri Pirttinen wrote:
> > If you don't see what's wrong about forcing every
> > single LPC2xxx chip to use "12 MHz" even if that's
> > not the *correct* frequency for their board ... I
> > don't know what more I could try to explain.
>
> I may have missed something
On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
> "Petri Pirttinen" napisał(a):
> > I may have missed something in here, but why trying to specify a crystal
> > frequency? Can't we use 4 MHz in here, IF we are setting the clock
> > source to internal RC oscillator in reset-init s
On Saturday 26 September 2009, Igor Skochinsky wrote:
> DB> REQUEST: someone with the IEEE JTAG spec, please verify that
> DB> entry to IR_Capture state is required to load the shift register
> DB> with x01 bits (as I'm told it does).
>
> Not the actual spec, but the Boundary-Scan Handbook sa
David Brownell pisze:
> Not clear on the status of those LPC2xxx things. I think they'd
> be ready to go if they didn't set up bogus clock rates...
All I'm doing is waiting for your suggestion to solve the "bug" (for me
that's not a bug [; ) - as I really see no other way for that stuff to
work
Hello David,
Saturday, September 26, 2009, 8:11:26 AM, you wrote:
DB> REQUEST: someone with the IEEE JTAG spec, please verify that
DB> entry to IR_Capture state is required to load the shift register
DB> with x01 bits (as I'm told it does).
Not the actual spec, but the Boundary-Scan Handboo
12 matches
Mail list logo
