Nathan Sidwell wrote:
It turns out that you can get the Code Worrier user's guide from without downloading the whole lot, from:http://www.freescale.com/files/soft_dev_tools/doc/user_guide/COLDFIREUG.pdfGlad you found that. We were unable to get permission to distribute those config files.
You have my permission to distribute my posted example cfg file, if that is of any use! Of course, with your new version just round the corner, I suppose it would not affect many people.
Our upcoming update to the tools has implemented a much better xml based initialization scheme, which we have fully documented. It specifies both board initialization and board memory maps.
I guess you need that for your support for flash programming as well, so that makes sense. I hope your flash programming utilities support command-line access, rather than forcing the use of a gui (as Freescale's flash program does, as far as I can see) - I like to have a "burn" make target during development.
I'd still like to know how to change cpu-space registers from with gdb, if anyone has any ideas - for some processors, it is important to be able to do things like turn caching on and off while debugging.This is not possible with the current gdb -- the bdm.sourceforge.net patches have not been contributed to FSF gdb. That said, control register access from gdb is on our todo list, but won't be available in the near term.
I suppose the trouble with using the bdm.sourceforge.net patches is that the copyright has not been transferred to the FSF, so that it could never become an official part of the gdb tree?
On other gdb + proxy setups I have used, the "monitor" command is used to pass commands directly to the proxy program, and as far as I know this is done without changes to gdb. The msp430 proxy program, for example, handles commands like "monitor erase" to erase the microcontroller's flash. That would perhaps be an easier route to add functionality than implementing bdm specific commands in gdb.
In the meantime you could include a function of the form
void set_cache_debug (unsigned v) {
__asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory");
}
in your application and use it from gdb with
(gdb) call set_cache_debug(0xWHATEVER)
Yes, that's what I had planned to do (although I had thought of setting up such functions from within my .gdbinit file rather than in the program being debugged). At the moment, the card I am working on has a MCF5213, and I don't need to write to any cpu space registers after the initial setup. I'll need it later for further work on an MCF5234 card, but that will be some time in the future.
nathan