Proof of concept, embedded OpenOCD

Development Boards MicroMod
1

Hello,

I have the crazy idea to port the OpenOCD to an embedded platform,

using a LPC2294 + ethernet. The OS port for the LPC2294 is now ready.

Here I am using Nut/OS (www.ethernut.de).

In the moment I can compile the OpenOCD source without any error or

warning. For the interface I use a bitbang interface which is control by the

LPC2294. The socket part is removed for the first step.

The next step is to get a working: jtag_validate_chain

The eval board has only limited resources (1MB SRAM). Does

anyone now why CMD_QUEUE_PAGE_SIZE is set to 1MB

inside jtag.c?

I will test it with 64KB, I hope this will working.

More is coming :smiley:

Best regards,

Michael

2

Hello,

some more information.

Now it is working, but not stable :frowning:

The transferrate from Insight was up to 9000bits/sec, very slow.

Perhaps this is the wrong CPU to do the job.

Regards,

Michael

3

Great work mifi.

I would not worry about the speed at this point. I am sure the speed can be improved once it is working.

The close coupling of the GDB Server to the JTAG will be fast in the long term.

The problem with GDB Remote is that the native way it loads code is very slowly. It does it a Word at a time waiting for an ACK.

This can be solved in 2 different ways

  1. Bypass GDB by using a native (monitor) way of doing it.

  2. Extend GDB’s functionality to do it natively.

The second method has the downside of either the patch being accepted upstream or continual patching :frowning:

The second method is the best in the long term however. The second method would fit in better with the GDB Remote protocol allowing all the data to pass over the same channel as the other GDB Remote information. It would also allow more rapid sending of code over serial ports to GDB Stub type systems.

I think a simple way of getting the code over quicker is to send the hex file over the link. It is pretty robust and split into convient chunks. I know a hex file is over twice as big as the binary file, but it is sending the data in chunks rather than one word at a time that gives the main speed up assuming the link is fast.

If the link is a 480Mbit/s USB link I think code loading could be pretty swift :wink:

Once you have proof of concept it can be taken on further.

4

What happened to this “proof of concept”?

Was it abandoned due to the slow speed?

I’d had a similar thought of having an embedded version of OpenOCD using Ethernet to talk to GDB.

I think an STR9 would be a good fit, as it can DMA through it’s SPI port and is configurable from 4 to 16 bits.

It would allow OpenOCD to be used entirely open-source without the FTDI binary. (yes - I know there is libftdi, but it’s unstable!!!)

Although have the disadvantage of maintaining/uploading firmware.

RFC?

5

Hello IG,

in the moment I am not working on the ethernet version.

Regards,

mifi