Re: My hat is off to Microchip and their CEO!

The JTAG section appears to not know anything about what the clock speed is other than requiring more than 32KHz to work.

I had incorrectly imagined that maybe because the JTAG actually clocks stuff in and out and in the process then also drives a single-step SYSCLK equivalent to advance through an instruction that it may provide that internal information on a display. It's very hard for me to imagine, when stepping using F11, that the JTAG uses the external clock. But perhaps my imagination is too limited.

Jon

This is the kind of gotcha you need to know about in advance when deciding what architecture to use.

and

hen

mer,

mply

do

in.

swer

I think that the clock is only needed to be able to stop the micro. I doesn't seem to care that much about the clock when it is running or already stopped. It gets very angry with me on the few cases where I tried to stop a micro that had no clock.

My initial board was without a crystal, so just using the internal one during initial code writing. Seems to work just fine. But I haven't tried to disable it first, either.

In any case, thanks for the suggestion and removing my desire to keep looking for a display on the debugger. It will save me bothering with that silly hope anymore.

Jon

using

and

then

counting.

timer,

on)

simply

I do

pain.

answer

contents

Jon, something to understand, standards are all about compromises. The JTAG standards were forced to be about functional verification rather than measuring performance because of this.

As I understand JTAG, broadly speaking, its simply a very long shift register. There is boundary checking, of course. But flashing and debugging, too. In fact, many internal registers and various flip flops are available that aren't all visible to the casual programmer, as well. It's not rocket science or even vaguely difficult to count cycles, as I gather it.

Jon

It most certainly is not. JTAG is a way to access internal registers addressed by commands. On top of JTAG there usually is a complicated, buggy protocol to access CPU registers (and memory if you are lucky).

Must be some other interface I remember, then. I was able to shift out and examine almost every internal flip-flop state, for example. Thousands of bits worth. Gave me access to pretty much everything, if the designers included the bits into the serial chain. I'd use test vectors which allowed me to set register values, both hidden and observable to a programmer, etc., before taking an instruction step.

I'll try and remember what exactly it was I'd used before, then. I'll take your point, for now. It's quite possible I've conflated JTAG with something else.

Jon

The designers don't want you to have that information. It's the family jewels. Emulation types get it only after signing a pile of contracts and giving up their first offspring.

No, these things are often accessible via JTAG. The interface could be "buggy" I suppose, though would highly doubt. It may not be well documented since it's not generally accessible by anyone outside the chip manufacturer.

then

Normally, I suppose. I think the ARM7 documentation discloses much, if not all. Or perhaps I'm wrong about that, as well. However, my case was for a different processor.

So are you saying that my original post is essentially correct, then? That JTAG is at its fundamental level a shift register chaining together state bits of possible interest? (It's how I'd imagined it up to now, until Nico wrote to tell me I was wrong, but I admit not being an expert in this area.)

Jon

then

timer,

simply

answer

Could be they've laid the whole design out hoping someone would copy it? Dunno, but this is usually *highly* sensitive information. We had a lot of hidden performance and feature switches in there that we certainly didn't want the user diddling with (or so much as knowing they were even there).

Essentially, though different manufacturers may use it differently.

That's pretty much it. "Of interest" may be the sticking point. Of interest to whom? The manufacturer has different uses than the user. Both may be accommodated in JTAG but the manufacturer my not disclose the information needed to get at the guts of the chip. For example, they may only disclose the boundary scan stuff for ICT and keep everything else a trade secret. The manufacturer may be able to get at every latch in the chip (as we did, though this was "free" because of the design rules) but I'd be very surprised to see one publish this information. ...if for no other reason than it changes from rev to rev.

JTAG is a requirement so why not use it for the kitchen sink too.

and

then

counting.

timer,

simply

do

pain.

answer

Thanks. I'm glad to keep my prior mental model and discard Nico's distraction from it.

Yes. That is implied. This is the internals we are talking about and that can get into nitty-gritty implementation details if the manufacturer decides to expose any of that. They could just chain together obvious things only. But then it wouldn't be nearly as useful.

The manufacturer has different uses than the user.

Personally, I would like _everything_ out on the table and in plain view. Intel would provide regular specification updates on their chips, including changes in package designators, bugs that apply to one and not another, and so on. It should be no real issue to include the complete JTAG chain disclosed for each stepping and change, as well. And let users beware.

If someone doesn't want to worry their pretty little head over these things, they can leave it to some commercial vendor to do. If they want to, then they can. Simple.

But disclose.

Hehe. I sure would. Expose every single state bit to the chain. Combinatorials don't have state, so no worry. If it holds a state, chain it.

Jon

then

timer,

simply

answer

The ARM documentation specifies most internals behind the JTAG interface. The documentation on how to access the registers through JTAG is usually a few pages. The 100+ pages describe the rest.

No, like I typed before: JTAG offers a bunch of registers addressed by a command register. Generally speaking: If you want to read pins, you'll need to send a command 'read pins' followed by several reads of the data register.

and

then

counting.

timer,

simply

do

pain.

answer

How do you know it's "most"? The architected registers are a *small* part of a design.

It's a floor wax *and* a desert topping.

been using

'cycle

of all, and

routine then

subtract.

counting.

set up a timer,

going on)

hoping they simply

=A0One way I do

and then

bit of a pain.

quick answer

contents

PCA for

maintained a

write

=A0From the

clock

clocks

single-step

for me

external

compromises. The

rather

shift

and

if

complicated,

lucky).

I'll

This may become impossible as the caches on modern processors are in the megabit range already.

using

and

routine then

counting.

timer,

on)

simply

I do

then

pain.

answer

contents

Yeah, well.... Our discussion has been there and past it. I think it may be important to pass along internal registers and latches for diagnostic purposes (ALU output latch, it's input latches if different from visible registers, bus latches, etc.) But I'm not terribly keen on chaining megabytes of cache. A small instruction cache might be nice (for example, the few k of cache that may be present on TI DSPs or ARM chips.) Of course, I'm focused on 8-bit and a few 16-bit parts for the most part. So this cache stuff rarely impinges on my tiny world. I'd probably be happy for more disclosures of the cpu core and peripheral chains.

Jon

been using

some 'cycle

best of all, and

a routine then

subtract.

manually counting.

set up a timer,

/12 going on)

hoping they simply

=A0One way I do

timer and then

bit of a pain.

a quick answer

the contents

the PCA for

maintained a

write

=A0From the

clock

actually clocks

single-step

may

hard for me

external

compromises. The

rather

shift

and

shift

example.

everything, if

test

step.

complicated,

lucky).

I'll

could

well

the

then?

this

=46ocus noted,

The minimum i would expect it all of the programmer visible stuff and all the I/O stuff. This is pretty much the definition from the JTAG working group itself. It is not a whole lot, but it does describe the basic compromise originally made by the initial JTAG working group.

using

'cycle

all, and

routine then

subtract.

counting.

timer,

going on)

simply

way I do

then

pain.

answer

contents

maintained a

clocks

me

Wonderful to meet in some common ground, then.

Jon