OPENCORES.ORG

Hi,

Hi.
I'll explain things once again...
- WRITE_COMMAND should be performed normally (the command is CPU read
(page 15)). - GO_COMMAND should be performed only partially (first 36
bits). Because the tms_i is set to 1, TAP goes to the "PAUSE" state.
In that state, instead of the CPU data, "busy state" state is shifted
out of the TAP to the JP2. If you continue shifting the data you'll
get the status all the time. So you keep on shifting and monitoring
the data that goes out of the debug interface to the jp2. Once the tdo
signal goes to zero, that means that the CPU is not busy (and data is
ready). Now you go back to the "SHIFT_DR" state and read out the data.

I hope this was clear enough.

Best regards,
     Igor

On Wed, 1 Dec 2004 20:24:58 +0100, György 'nog' Jeney
<nog@s...> wrote:
> Hi,
> 
> In the documentation of the debug interface on page 44, section 4.3.10.1 it
> talks about reading from a slow cpu.  Then it goes on to say: `Perform a
> WRITE_COMMAND normally' and then it says to assert tms_i after the 36th bit has
> been shift *out*.  I'm guessing that `shifted out' is from the view-point of
> jp2.  If this is the case then these semantics reflect that of the READ_COMMAND.
> So it seems like a this WRITE_COMMAND should really be READ_COMMAND.  Is this
> correct?
> 
> nog.
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores
>