Remote Flashing w/ Window Client & OpenOCD

I am almost ready with the Remote Flashing with Window Client running Keil with hex output and OpenOCD server on Linux. Anyone out there willing to test the code?

The files (flash.c and stellaris.c) have been modified to support loading hex file and flashing from target memory. The remaining task is to figure out how to initiate it.

Since OpenOCD supports both GDB and Telnet servers, we can use either option.

Option 1: Add "$f,,,#XX" on GDB protocol

Option 2: Add "load from " on Telnet protocol.

Please comment on the changes and vote for one (the other will have to wait). Thanks.

Changes posted at:

formatting link

Reply to
linnix
Loading thread data ...

It seems that flash.c and stellaris.c are not enough for the changes you made - flash_driver_t is defined in flash.h, and doesn't have a "mode" member.

Generally, I don't think it should be necessary to modify any of the flash drivers to support remote downloads. Changes would be necessary to implement the "flash from RAM" you mentioned, but I'm not sure why you need that.

I'm currently implementing a file I/O helper that takes care of accessing the files to avoid having this in every subsystem separately. This could easily be extended to handle HEX files and possibly ELF files, too. If remote access is desired, adding [XYZ]Modem support to the telnet interface might be a straight forward choice, but I'm not sure how complicated these are.

The new GDB 'f' packet would be more work, because as I understand it the remote target would have to provide a XML file describing the memory map to the GDB client.

We also have a mailing list for OpenOCD development at

formatting link
where Magnus Lundin, the developer of the Cortex-M3 support, is subscribed.

Best regards,

Dominic

Reply to
Dominic

Yes, I didn't bother to post the .h, just add the .mode member to it.

My remote client (on Window) first upload data into target sram, then issue a command to flash it. Problem with existing code is that the file must be on the server first.

Telnet interface is not as easy as GDB. Packet size and format are easier to control in GDB, where Telnet can be anything. My Window client already have GDB and I hate to add another protocol to it.

No, the remote client dumps into the target memory directly.

at

formatting link
Magnus

Reply to
linnix

I tried contacting you through the form at

formatting link
but maybe that didn't work. Could you please make sure that the complete source code used to create the binary you're distributing is available, including the COPYING file?

Ah, I never thought of such a scenario. I suppose you're using the GDB protocol's M or X packet to write target memory, and all you now want to do is trigger a copy from memory to flash.

The "clean" approach would be the use of the new vFlash command (I mixed that up with the "$f,..." you wrote about), but when using a "real" GDB client that would also require the use of an XML description file that tells the GDB when to use memory access (M, X) and when to use flash access (vFlash).

A simpler alternative that's still usefull for other uses would be a "flash copy " command, if you're interested in getting these changes upstream. If what you want is a private fork that's only meant to work with your own Windows client then you can of course use whatever is easiest for you to implement.

Regards,

Dominic

Reply to
Dominic

Yes, I got that. I've been just too busy to get the code working.

OK.

Yes, a write command as well as a erase command. Alternatively, I can always erase before write. Currently, I "M 64 bytes" to the server and issue a write. I ran into a buffer size problem for 128 bytes, but it could be Window Socket problem. I need a long delay between command and response, so bigger buffer size would be better.

Is vFlash a telnet command? I would like to have a GDB command, to avoid opening a different port.

Yes, in fact, I would be storing different version in high flash, and "test" different versions as needed. My program currently takes 10K out of 64K. For now, I just need a quick and dirty fix, we can think about that later.

Thanks.

Reply to
linnix

The buffer used for packet handling is currently 2048 bytes (GDB_BUFFER_SIZE in gdb_server.h), enough for ~1000byte of hex-encoded data. The code that converts the hex string to binary is also rather simple, so that should be working fine, too.

vFlash is part of the GDB remote protocol since version 6.6:

formatting link

Note that you don't need to open a telnet port when you want to sent commands to the OpenOCD's command interpreter - just use GDB's "qRcmd" packet (monitor from within a GDB session). You could use that to call a "flash copy ..." command for example. The only commands that shouldn't be sent via qRcmd are commands that affect the target state, like resume or reset (without halt/run_and_halt), as the GDB wouldn't know about the state change.

Regards,

Dominic

Reply to
Dominic

Got it. The stupid Window Socket class (somebody's code) uses a 256 bytes buffer. I will increase it.

6.6:
formatting link

OK, sound good, will do that.

Reply to
linnix

OK, increased bulk transfer of 64 bytes, which caused 590 bytes write to the USB FTDI. Tried 128 bytes and caused 1100 bytes USB write and the FTDI choked on it.

I guess I have to break down the packet in GDB code before sending it to FTDI.

The fun never end. No offend intended to you, Domicic. but who said open source is free? It's cheap, but not free.

6.6:
formatting link
Reply to
linnix

Did you try the (not free, but gratis) FTD2XX driver from FTDI? I've run into all kinds of problems with libftdi, and I always intented to work on fixing it, but the low level details of the FT2232C aren't well documented. Since the OpenMoko project is using the OpenOCD to debug the Neo1973 this might change, as they're using libftdi instead of FTD2XX.

There's a fix for ft2232.c when using libftdi in the latest trunk release (added because of a bug report from OpenMoko):

formatting link

This fixes initialization problems (sometimes the OpenOCD couldn't talk to the FT2232 when using libftdi, and required a restart) and at least on the few tests I ran it also cured the choking on large packets, but maybe that's just a coincidence and the problem is still there.

Heh, I'm sure that's not what you want to hear, but the 'free' in 'free software' is about being free for you to use any way you like, and I suppose your case shows that it nicely plays that role.

The free as in beer/gratis is something that's usually disregarded among the free software community.

But of course you are right, the OpenOCD needs more work for setup and learning than a commercial offering.

Regards,

Dominic

Reply to
Dominic

There are two major issues I have, perhaps they are related. I have to divide the clock by 256 (jtagclock = 8 or 9) and cut down the buffer to 512. I guess the slow jtag clock is backing up the internal buffer of the FTDI. I need to slow down the jtag because the LM3S811 is reporting data overrun otherwise.

So, it might just be a combination of all these factors.

Reply to
linnix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.