Steven Johnson wrote:
There dosn't need to be a leak, anyone with a spare afternoon could
probably reverse engineer it.
i'm sure that you would need somewhat longer...
> We already know what the flash
programming codes are. How a JTAG Port works is well documented. I
programming is not the problem, you can also use msp430-jtag
cant see it being a huge task trapping the jtag sequences, and working
out what Jtag Registers are being set/read with what value during
various operations such as setting breakpoints, single stepping, saving
and restoring context, etc. There would only be a handful of operations.
in theory, but not in practise ;-)
This could be done with the IAR back end operating the FET, or
GDBProxy. It would be an interesting exercise, especially if IAR is 6
times faster as this email suggests. (maybe they know some secret
accelerated programming method).
well, knowing where gdbproxy spends its time, making its download rate
sink, would be interesting.
chris
Steven
nobo...@web.de wrote:
Hi,
mspgcc-users@lists.sourceforge.net schrieb am 31.05.04 20:50:22:
Hi Rolf,
1) Speed:
These lines should fix your speed problem, many people have already
mentioned them ;-)
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
Ok, it's significant better but approx. 6 times slower than the IAR
debugger.
Because i have to work with f149 code which has less than 100 B flash
free it's still very slow.
2) Port number:
Dunno. On this topic though, does anyone know if it's possible to
use the
USB FET or is support being planned for it with insight/gdb? Eg:
http://www.softbaugh.com/ProductPage.cfm?strPartNo=USBP
I remembered that it may be a problem with the closed source of the
debugging hardware which would imply that the software of a jtag
device has to be closed source.
Maybe we have to wait for a leak, like the windows code in emule ;-)
Rolf
