Hi all,
I noticed that quite a lot of people are working on JTAG tools
for debugging on the LPC, but (as far as I know) there is still
no-one that has written an open-source gdb stub for the LPC family.
On sourceforge, there are a couple of gdb JTAG projects for arm
processors, but none seem to support the ARM7TDMI-S.
Existing closed-source software like OCDRemote and OCDCommandor
does not work well with my olimex wiggler clone and there's nothing
I can do to fix it.
Myself, I played around a bit with the sources from
http://gdb-jtag-arm.sourceforge.net/ ,
probably re-inventing the wheel but it was fun nevertheless.
So far, my progress is:
* updated parallel port access code to use libieee1284. This makes
the tool portable between windows/cygwin and linux.
* made it work with a cheap wiggler clone from olimex.
* can read JTAG idcode
* can read and write ICE registers
* can stop the processor
* read the CPU registers (not reliably yet and in wrong order)
Can we perhaps combine forces and write an open-source gdb stub?
Kind regards,
Bertrik
Combining forces on open-source gdb stub
Started by ●December 15, 2005
Reply by ●December 15, 20052005-12-15
I'm currently working on such debugger (10% done).
Features:
- USB connection / next release on Ethernet (with TCP/IP server)
- fully compatible with gdb remote protocol (no server like ocdremote
needed)
- SW/HW breakpoints
- Full EmbeddedICE/JTAG debugging or with LPC integrated Realmonitor
Schematics and firmware (PIC18/ezUSB) will be available on my website.
I'm waiting my DIL LPC2106 for the prototype.
Features:
- USB connection / next release on Ethernet (with TCP/IP server)
- fully compatible with gdb remote protocol (no server like ocdremote
needed)
- SW/HW breakpoints
- Full EmbeddedICE/JTAG debugging or with LPC integrated Realmonitor
Schematics and firmware (PIC18/ezUSB) will be available on my website.
I'm waiting my DIL LPC2106 for the prototype.
Reply by ●December 15, 20052005-12-15
Hi Bertrik,
I am wondering if you have seen this:
http://openwince.sourceforge.net/jtag/
It appears to support wiggler.
Maybe all that is needed is some tweaks for ARM7.
Some people have used this on x-scale.
-- Doug
I am wondering if you have seen this:
http://openwince.sourceforge.net/jtag/
It appears to support wiggler.
Maybe all that is needed is some tweaks for ARM7.
Some people have used this on x-scale.
-- Doug
Reply by ●December 16, 20052005-12-16
Bertrik Sikken wrote:
>I noticed that quite a lot of people are working on JTAG tools
>for debugging on the LPC, but (as far as I know) there is still
>no-one that has written an open-source gdb stub for the LPC family.
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!
Rob
>I noticed that quite a lot of people are working on JTAG tools
>for debugging on the LPC, but (as far as I know) there is still
>no-one that has written an open-source gdb stub for the LPC family.
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!
Rob
Reply by ●December 16, 20052005-12-16
On Friday 16 December 2005 03:56, Doug Sutherland wrote:
> Hi Bertrik,
>
> I am wondering if you have seen this:
> http://openwince.sourceforge.net/jtag/
>
> It appears to support wiggler.
> Maybe all that is needed is some tweaks for ARM7.
> Some people have used this on x-scale.
>
> -- Doug
>
Hello Doug,
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?).
Regards,
Dominic
> Hi Bertrik,
>
> I am wondering if you have seen this:
> http://openwince.sourceforge.net/jtag/
>
> It appears to support wiggler.
> Maybe all that is needed is some tweaks for ARM7.
> Some people have used this on x-scale.
>
> -- Doug
>
Hello Doug,
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?).
Regards,
Dominic
Reply by ●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
> 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
Reply by ●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
> 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 ●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
> 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 ●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
> 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 ●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
>
> 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
