6

I am debugging some code written for the MSP430F2132, which has very little flash memory available for the program. In order to debug properly, I must send information out to a terminal so that it can be stored and viewed at a later time. Normally I would use printf or a similar command (putchar, perhaps) and have it linked to the CCS 6.1 console. However, due to the lack of program memory on the micro, I am unable to use these functions. I also do not have the option of modifying the board to make use of a built-in UART channel on the micro. I am connected to the micro using the MSP-FET430UIF USB debug interface, which supposedly implements a back-channel UART interface but I think this requires special connections to the target that I do not have. Do I have any options that use very little memory that would allow me to store debug information? I just need to send two long ints each cycle.

EDIT:

Upon further inspection (the design was not originally mine), I notice that the "special connections to the target" required for the MSP-FET430UIF (simply to the UCA0RXD and UCA0TXD pins on the target micro) do exist, but the signals are converted to RS-485 using transceivers on the interface board (a test fixture) and the target board. Perhaps I can use the FET430UIF backchannel UART after all, though I have yet to find good instructions on how to do that. If anyone here has experience doing this and will be able to offer guidance, it would be very helpful.

DerStrom8
  • 21,042
  • 8
  • 61
  • 95
  • You don't say what ultimately happens with those RS-485 signals. Can you get at the TXD/RXD signals (with 3.3V CMOS levels) somewhow? – CL. Mar 17 '17 at 08:36
  • I did some more tracing and it seems that these TXD/RXD signals are not connected to the FET430 after all, as I originally thought they were. Instead, they are connected to an RS232-USB chip on the interface board, and passed out over another USB cable. I think that may be my ticket, I don't think there's a way in my current setup to use the FET430 back-channel UART – DerStrom8 Mar 17 '17 at 10:45
  • Back-channel UART is inherently a simple UART after all. In any scenario you will end up - most likely - with a COM port on your PC, and it's irrelevant how you will get it. Just use any UART that you can get from you target and you'll be fine. GL! – Andrejs Gasilovs Mar 18 '17 at 14:01
  • Might not be as good as what you want, but if you have space you can stuff data into a RAM buffer, then pause the program and inspect it with the debugger (maybe some time after the important even t happened). – The Photon Apr 08 '17 at 15:53
  • I actually tried this, but the buffer size had to be extremely small due to the amount of available RAM on the device. I was eventually able to talk to the micro over a separate UART connection (not through the FET430), which really did everything I needed it to. I just sent out the data as it came in, and collected it using PuTTY – DerStrom8 Apr 08 '17 at 21:58
  • potentially related (?) question: [MSP430 printf() through Spy-Bi-Wire hangs](https://electronics.stackexchange.com/questions/59419/msp430-printf-through-spy-bi-wire-hangs) – Nick Alexeev Jan 15 '18 at 02:00
  • @NickAlexeev I'm afraid not, the problem isn't that printf() causes the interface to hang, the problem is that it takes up too much code space and won't fit in my design. I was looking for an alternative method of sending long ints to the CCS console that doesn't take up as much code space – DerStrom8 Jan 15 '18 at 12:01
  • When working with MSP430 I've always debugged the software with the CCS watch window, it works fine and allow almost realtime update. Maybe this is sufficient for you too. – user162889 Feb 12 '18 at 23:03

1 Answers1

1

If you have functioning JTAG connection, you can use the CCS built-in debugger for all your debugging needs.

Just store your debug values in an array and optionally set up an "if" clause with __no_operation() for a breakpoint to check what's going on periodically. Or just pause execution after you come back and see the collected data.

Alternatively, instead of using the memory hungry printf to stdout, you can write to stderr with fprintf. It's by far slower and uses no buffering but for periodic status reports it may be enough.

Barleyman
  • 3,568
  • 14
  • 25