Hi, This is just a tip for users of gdb and mspdebug - slow debugging had been annoying me, and it took me a while to find a solution. I had originally planned to ask about the issue here, but since I found the answer myself I thought I'd tell others about it.
By default, gdb considers all memory areas to be non-cached (i.e., it reads them from the hardware every time it wants to show them) and uses native sized accesses. This means that if it wants to read code, such as to show the disassembly window, it has to do an awful lot of 2-byte reads from the chip - often reading the same address several times. As there is a certain latency for each read, this can mean long delays while everything is read and re-read (you can see this on the output of mspdebug). The way to avoid this is by memory regions. In the gdb setup, include two lines about memory: set remoteaddresssize 64 set remotetimeout 999999 set remote memory-write-packet-size 2048 set remote memory-write-packet-size fixed set remote memory-read-packet-size 2048 set remote memory-read-packet-size fixed set mem inaccessible-by-default off mem 0x2100 0x100000 ro 64 cache The exact range for the "ro 64 cache" memory area will depend on the chip you use, but it should cover the code flash. gdb will then know that it can use 64-byte reads in this area, and can remember the results - substantially cutting down on extra reads. mvh., David ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
