SparkFun Forums

[mifi]

Hello,

I am thinking about how to speed up OpenOCD by hardware. Therefor I have the following idea.

In the moment you can use for example a hardware based on the FT2232 chip.
But this chip has a max JTAG clock of 6MHz. What I now want to do, use a hardware with the
power of an external CPU, like LPC2214 or STR710 and a CPLD.

Why these CPUs?

For the USB I would like to use an FT245, memory mapped to the CPU. I think only these
ARM CPUs has an external memory interface. The JTAG interface should be realize by a CPLD.

The CPLD is memory mapped too in the address space of the CPU. The CPLD could be clocked
by a PLL. With this trick the JTAG speed can be changed.

Why FT245?

It is possible that the USB from the STR710 can be used too, but with the FT245 we does not
take care about USB in the CPU and USB driver for the PC.

Could this boost the speed of OpenOCD?

Certainly, this must be an OpenSource (OpenHardware) project too.

What do you think?

Best regards,

Michael

[bernardf]

Do you have particular transfer speeds for particular targets in mind? Actually I'm interested in the STR71x target and openocd is slow with it, at least for flash writes. For RAM writes or JTAG execution, it is acceptable (However I don't have other points of comparison, I'm new to continuous JTAG use, I'm more used to proprietary probes like ATMEL's AVRISP)

In the case of Linux/Openocd/Str7/Amontec JTAG/Flash write, slow speed has nothing much to do with USB transfer speed or pure crunching power. From what the oscilloscope shows, any JTAG query-answer takes 6ms, probbably because of Linux scheduling, libftd2xx sequence of system calls, etc. The easiest trick to get more speed is to delocalize some processing done inside openocd in the target itself instead of processing everything needed to flash write thru the USB bus. This way the 6ms latency between each query disappears.

Thinking about it again, I guess that the performance bottleneck is probably libftd2xx itself: if you strace(1) openocd, you see that each JTAG query makes a lot of system calls. For instance memory is mapped/unmapped each time, instead of being mapped once for the time openocd runs. If you gprof(1) openocd, you'll see also that some internal functions are called hundreds of thousands of time when you write 64k to the STR7 flash.

So I guess there is still much to do at the software level before having to think about making dedicated hardware. To start, IMHO one should clearly find where time is lost, it is still unclear at the moment but libftd2xx would be a good starting point. Too bad that it is the only part of the sofware chain that is not open source...

[mifi]

Hello Bernard,

I have no particular speeds in mind, I have worked with the
CrossWorks tool too. And here the download speed feel faster
than with a FT2232 device.

But I heard the good news from the other topic:

"str7 flash write: 4 last bytes not copied"

>and is now able to program the 256kb flash of a STR711 in about 8 seconds

Very nice work Dominic!

Regards,

Michael

[fordp]

I suspect that the FTDI Chips clock of 6Mhz is actually very fast. The FTDI chip is not a dedicated JTAG device so I suspect that it no where near achieves what could be done at 6MHz.

I think one way to get good performance would be to run the actual OpenOCD code on a fast microcontroller which has a CPLD attached.

Not everybody needs such fast performance however, I am using the LPC2103 at the moment which has only 32K of Flash and 8K Ram so download speed is not a major issue at this time.

This would change if ARM926EJS support were added as I would be using it on a Platform with 8M flash and 16M of RAM. Then having a fatser version would be more interesting.

All the best.