John Heenan writes:
> So I acknowledge
> 1. Use of RTCK cannot raise throughput during the non debug state
> 2. During debug state the 1/6 rule applies
>
> However I will not acknowledge that the entire set of enforcements is
> strictly necessary.
Agree, but I am not sure how the DBGTCKEN is used by the EmbeddedICE module.
If what I think is true you would be able to clock in data at a higher
speed (up to CLK?) after having your first positive edge on RTCK. This may
- or may not - work and I'm not in the mood for trying this out myself.
I'm currently using an lpc21xx to control the JTAG of the next one using
software. If you start using a TCK > 1/6 CLK (if possible at all ...) then
you need to take care of RTCK synchronization in a completely different
way.
> Informative links are
Thanks, I had not seen the timing diagrams (they were not in my pdf file)
but I have figured things out from the schematics. My software is also
using the adaptive clocking mode as described in software:
- set TMS & TDI to correct values
- raise TCK
- wait for RTCK
- drop TCK
And then wait for RTCK to be low before the next bit to write.
This works, I am able to talk to the EmbeddedICE registers without any
problem. Communication with the Debug Communication Channel (DCC) is also
no problem.
I am now reading that part of the spec where it tells me how to clock the
instructions into the chain. It's all about reading the documentation
carefully ...
RobMessage
Re: [lpc2000] Re: Slow OCD Remote/Insight debugging. Hard information from logic diagrams
2005-10-08 by Rob Jansen
Attachments
- No local attachments were found for this message.