At 19:05 26-07-05 +0100, you wrote: >We have just developed a board based on the msp430 f1491pm chip and gout it >running today. >We made a late decision to use the new chip after a TI presentation as it has an >on-chip DAC. > >To my horror, I discovered that gdbproxy doesn't recognise the chip. I had assumed >that it would recognise it as one of the 149x family but that is not the case. > >Is there current/imminent support for this device? A patch that makes it a generic >149x would be ok. If not then we must look for another toolchain which would be >really sad as we want to stick with gcc is possible.
I don't have a direct solution to this problem. But what keeps me wondering is why so many people use in-circuit emulators / debuggers for debugging embedded devices. The whole 'problem' comes down to verifying software and being able to locate bugs. I have been using the following approach for nearly a decade on different platforms: I use the serial port to run a command line interface (about 80 lines of code) and implement putchar to make printf work. The command line interface allows me to execute seperate parts of the software, dump & alter parts of the memory, input stimuli, etc, etc -the sky is the limit-. For example, I've made firmware which allows to switch on debugging in certain parts of the software to keep track on what the software is doing. This allows customers to provide detailed information from the field for further analyses. If things get really complicated, I write and test an algorithm on a PC first using GCC which offers easier ways to verify software. Nico Coesel
