Reply by Bertrik Sikken December 21, 20052005-12-21
Hi all,

Dominic Rath wrote:
> The differences are actually very subtle, and not much of a problem,
> if the code is written with -S cores in mind.
>
> If you want a snapshot of my current development tree mail me, I can
> give you access to my private CVS or a tarball. I didn't release this
> new code yet as it's not really usable at the moment.

Dominic released a preview version of the openocd package
(check out the svn archive for the very latest version)!

I created a wiki page with some basic instructions on how to get
started with it for anyone interested:
http://wiki.sikken.nl/index.php?title=ArmDebug

All the best,
Bertrik

An Engineer's Guide to the LPC2100 Series

Reply by Eric Engler December 18, 20052005-12-18
--- In lpc2000@lpc2..., "Michael Rubitschka" <rubitschka@h...>
wrote:
>
> Yes it is interesting, but for Arm9 only.

I haven't looked into this myself, but the manual says it supports
both Arm7 and ARM9, and the history says that ARM7TDMI was supported
first, before Arm9.

http://jtager.sourceforge.net/

I am not implying that this is the best starting point, but only that
there may be some value in looking at it.

Dominic Rath's work seems like the best starting point, and I agree
with the reasons posted by someone here recently (can't remember who):
best documented, and the only work of relevance that is still
undergoing development. Either one of these reasons alone would make
it a no-brainer.

Eric
Reply by Michael Rubitschka December 17, 20052005-12-17
>This one is also interesting:
>
>http://jtager.sourceforge.net/

Yes it is interesting, but for Arm9 only.

Cheers
Michael
Reply by Eric Engler December 16, 20052005-12-16
--- In lpc2000@lpc2..., Doug Sutherland <doug@p...> wrote:
> I am wondering if you have seen this:
> http://openwince.sourceforge.net/jtag/

This one is also interesting:

http://jtager.sourceforge.net/
Reply by Rob Jansen December 16, 20052005-12-16
Bertrik Sikken wrote:

> It appears to be incomplete. None of the differences I've seen
>
>so far is even mentioned in appendix B.
>
>

The differences are not as big as you describe.
I used an ARM7 TDMI debugger pod on the TDMI-S, it works but sometimes
it just hangs.
The biggest difference is the removal of the scan chain around the core
(which is not used by the debugger) and the addition of the Return Clock.
Adding the return clock is an easy task - but you'll have to add a bit
to the I/O configuration.

I think the OpenOCD is a good start for a debugger. It's well
documented, very recent and Dominic is still working on it (most other
projects are old zombies wadering around the internet ...)

Regards,

Rob
Reply by Bertrik Sikken December 16, 20052005-12-16
> The differences between ARM7TDMI and ARM7TDMI-S are listed in
> Appendix B of the ARM7TDMI-S technical manual.
>
> http://www.arm.com/support/faqip/3686.html
>
> Perhaps that info would be useful.

It appears to be incomplete. None of the differences I've seen
so far is even mentioned in appendix B.

Bertrik
Reply by Dominic Rath December 16, 20052005-12-16
Hello,

>
> Yes, I saw it.
> It does not support ARM7TDMI-S yet, only ARM7TDMI, right?

Yes, the code available at berlios is from july, and doesn't support -S cores.
Besides, it has some nasty bugs, so I decided to rewrite most of it.

> What would it take to add support for the ARM7TDMI-S / LPC family
> to openocd?

My new code I'm working on supports ARM7TDMI-S, specifically LPCs. I have one
LPC2294 here to test with, which is why I've subscribed to this list.

> Which existing project do you guys see as the best candidate for
> extension with ARM7TDMI-S support?

I wont comment on this one ;)

> I won't mind helping with writing the code or testing it.
> So far I see the following differences to be handled:
> * debug control ICE register (different bits)
> * DCC control ICE register (different length)
> * data bus scan chain size

The differences are actually very subtle, and not much of a problem, if the
code is written with -S cores in mind.

If you want a snapshot of my current development tree mail me, I can give you
access to my private CVS or a tarball. I didn't release this new code yet as
it's not really usable at the moment.

>
> Kind regards,
> Bertrik
>

Best regards,

Dominic
Reply by Doug Sutherland December 16, 20052005-12-16
Bertrik Sikken wrote:
> It does not support ARM7TDMI-S yet, only ARM7TDMI, right?
> What would it take to add support for the ARM7TDMI-S / LPC family
> to openocd?

The differences between ARM7TDMI and ARM7TDMI-S are listed in
Appendix B of the ARM7TDMI-S technical manual.

http://www.arm.com/support/faqip/3686.html

Perhaps that info would be useful.

-- Doug
Reply by Bertrik Sikken December 16, 20052005-12-16
> Well, there is openOCD from Dominic Rath. He created an "On-Chip Debug
> solution for embedded target systems based on the ARM7 and ARM9 family".
> His Diploma Thesis is a great piece of documentation with lots of
> information on JTAG and ARM7/9 debugging.
> The code even has support for the FT2232 from FTDI and schematics for
> the hardware are given in the thesis.
>
> Look at: http://openocd.berlios.de/web/ It's worth it!

Yes, I saw it.
It does not support ARM7TDMI-S yet, only ARM7TDMI, right?

What would it take to add support for the ARM7TDMI-S / LPC family
to openocd?

Which existing project do you guys see as the best candidate for
extension with ARM7TDMI-S support?

I won't mind helping with writing the code or testing it.
So far I see the following differences to be handled:
* debug control ICE register (different bits)
* DCC control ICE register (different length)
* data bus scan chain size

Kind regards,
Bertrik
Reply by Doug Sutherland December 16, 20052005-12-16
Dominic Rath wrote:
> the openwince jtag tools use the boundary scan chain around all device pins.
> This gives them access to the data and address bus, and allows them to
> read/write the flash. This doesn't include any debugging support. LPC doesn't
> have a boundary scan chain at all (none that I've found?).

Hi Dominic,

Thanks for the info, and also thanks for sharing your work. I suppose
there are are things that most people are looking for:

Ability to program internal flash
Ability to program external flash
Debugging support, especially GDB
Boundary scan to test new boards

Some of these may not be applicable to a typical LPC2000 application,
but I find myself requiring other vendors' ARM chips also. In particular
I'm interested in STR7 for peripheral support (4 UARTS), Cirrus Logic
and Sharp for audio and MMU support (ARM720T), and also basically the
same on ARM920T (looks like Atmel might be good here with AT91RM9200).

I haven't had a chance to try your code yet but I will try it in the
next few weeks.

-- Doug