Re: Remote Flashing w/ Window Client & OpenOCD

On Feb 28, 4:03 am, Dominic <Dominic.at.use...@xxxxxxx> wrote:
linnix wrote:
Yes, I didn't bother to post the .h, just add the .mode member to it.

I tried contacting you through the form athttp://linnix.com/ocd/but maybe
that didn't work.

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

Could you please make sure that the complete source code
used to create the binary you're distributing is available, including the
COPYING file?

OK.


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.

[snip]
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.

[snip]
No, the remote client dumps into the target memory directly.

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.

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.


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).

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


A simpler alternative that's still usefull for other uses would be a "flash
copy <bank> <source-address> <destination-address>" 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.

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.


Regards,

Dominic

Thanks.


.

Relevant Pages

  • Re: Remote Flashing w/ Window Client & OpenOCD
    ... Telnet interface is not as easy as GDB. ... the remote client dumps into the target memory directly. ... is trigger a copy from memory to flash. ...
    (comp.arch.embedded)
  • kgdb cleanups
    ... -platforms with the kgdb option may behave in a similar fashion. ... the thread info command and gdb now seems to ask when needed. ... -#define COMMA, ...
    (Linux-Kernel)
  • [UNIX] Lukemftpd (Tnftpd) Multiple Vulnerabilities May Lead To Remote Code Execution
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... structure tab to indicate if it's acceptable for a command to occur in OOB ... delivering of ABOR and STAT commands in OOB mode. ...
    (Securiteam)
  • Re: Wireless IOS upgrade on 881W
    ... The info below is on the right track - use the "archive download" command ... to load the tarball into the AP801's flash. ... However the integrated AP - do I load the file as it is on ... ~ There is a command to connect to the wireless module ...
    (comp.dcom.sys.cisco)
  • Cant get HC12 EVB and metrowerks to program Flash on target board via BDM
    ... Looking at the communications between the debugger and the EVB board, ... I see that when I load RAM successfully, ... 0800 command. ... When I try to write to flash memory, ...
    (comp.arch.embedded)