> > This seems to me to be a round-about method. If all you want to do is > > program the msp430 using C-spy, then just use hex files - objcopy will do > > elf-to-hex conversion, and C-spy will happily read and program it. > > > > I wasn't aware of that route. However... > > > If you are looking for a slightly more capable debugging system using C-Spy, > > then as far as I know the best method at the moment is to use objdump to > > generate a copy of the object code in iar assembler format, with the > > original C code embedded as comments. This can then be assembled and > > compiled using iar's free tools, and loaded into C-Spy. > > > > I used to do exactly that. But, it required a good few steps that couldn't > be done by the makefile under linux (which was annoying), and certainly in the
It can be done under cygwin with a makefile (the iar tools have command-line versions). But I don't know how well these can work from make in linux - presumably you need to run them with wine. > early days the IAR assembler output of objdump was quite buggy (which yielded > some very inpenetrable bugs in running code). I contributed quite a few > disassembler fixes for such problems myself back in June/July last year. > There were a few bugs (I contributed a patch myself), but it was certainly workable. > However, none of these routes offered the possibility of letting C-SPY use > a symbol-table properly. That's what I'd hoped the direct creation of a That was the real problem. I thought about trying to improve this (by getting some symbolic information from objdump, and making a bit more iar-assembly code providing the information to C-Spy), but it could never be more than basic symbols since there is no documented way of describing structures or arrays from iar assembly. It would have been a hack at best, and I dropped all ideas about it once gdb and rproxy were working (on my w2k machine at least). If I remember correctly, the iar assembly output has been dropped from the latest binutils as well, although I may be wrong about that. > UBROF file would permit. Hence all the effort to that end. Of course I got It would be a huge benifit to users and developers of embedded tools for a range of processors if the ubrof format were openly documented. Unfortunately, it is not, and that means that a complete ubrof generator is going to be a tough project. > overtaken eventually by native linux support for JTAG downloads, but having > said that, I've not yet actually managed to get msp430-gdb/rproxy to work. > While your ubrof converter is definitely of interest, with a much wider audience than just the msp430 gcc users (try posting to comp.arch.embedded to see who's interested), the more direct route now is gdb/rproxy. I wish you luck in getting it to work! > And the non-linux/non-i386 people never will until the JTAG interface software > goes open source. > Perhaps the closed bits could be written in a byte-code interpreted language such as java (python would probably be too slow for this sort of thing, unless you used an accellerator like psyco and thus lose the benifits of cross-platform compatibility). Other than that, if there was enough demand (or money!) I'm sure the couple of guys with the source code could compile it for other architectures.
