At 18:25 22-03-08 +0000, you wrote: >On 2008-03-22, N. Coesel <[email protected]> wrote: > >>>> I always try to stay away from JTAG as much as possible. Here >>>> is my recipe: use the BSL serial method to download software >>>> into the MSP430 device. Debug code while running it on the PC >>>> (compile for Linux of Windows). Make a command line interface >>>> to do final debugging in the device itself. >>> >>>Putting a command line interface into something with no serial >>>port and a couple K of flash and couple hundred bytes of RAM is >>>pretty tricky. I often use a bit-banged "putc()/puts()" for >>>debugging, but there's often not enough ROM/RAM to implement >>>even a limited printf(). >> >> In that case I use a bigger device with the same pheripherals to develop on >> and recompile for the smaller device when finished developing (switching >> off all debugging with a define). > >That's a pretty good plan if you can find a "bigger" device >with the same footprint. Prototypeing and testing with an eval >board that has a bigger part with at least some of the same >peripherals can also be useful if you got a way to wire up the >port pins to "real" hardware.
Creating a prototype which has the big device on it is an option. Or create a small board which can be connected to the small device's footprint with thin wires to replace the small device. This is not difficult at all if you use very thin wire. Thin wire will be pulled into the middle of the TSSOP pads by the surface tension of the molten solder. There are many ways that lead to Rome. Being able to set breakpoints can be very handy to check for correct program flow, but it is not suitable for real-time processes so the use of breakpoints on a microcontroller is quite limited compared with debugging on a PC. A command line interface which can report status (number of loops, detected errors, transmitted bytes, etc, etc) is a good way to debug real-time processes. Nico Coesel
