At Wed, 7 Mar 2012 15:15:30 -0800, wayne roberts wrote: > I have set a breakpoint at main(), and confirmed the msp430 is running from > reset vector after "monitor reset" then "continue". (it halts at main again) > > Yet, I am also using gdb on another platform, where i can single step after > issuing "monitor reset", and the cpu is executing first instruction in > Reset_Handler. > (this other platform is codesourcery arm-none-eabi-gdb with a segger > gdb-server to cortex-m3) > If I wanted to find out whats happening, I wonder if i can use tcpdump to > sniff the socket to gdb server?
You could, but I don't think it would help -- the protocol doesn't allow for register information to be returned after a monitor command. However, I've found a workaround. Just issue "flushregs" at the GDB prompt after "monitor reset". This appears to force GDB to re-read the registers from the server. Cheers, Daniel -- D.L. Beer Engineering www.dlbeer.co.nz ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
