6
\$\begingroup\$

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.

\$\endgroup\$
8
  • \$\begingroup\$ 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? \$\endgroup\$
    – CL.
    Commented Mar 17, 2017 at 8:36
  • \$\begingroup\$ 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 \$\endgroup\$
    – DerStrom8
    Commented Mar 17, 2017 at 10:45
  • \$\begingroup\$ 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! \$\endgroup\$
    – Andrejs Gasilovs
    Commented Mar 18, 2017 at 14:01
  • \$\begingroup\$ 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). \$\endgroup\$
    – The Photon
    Commented Apr 8, 2017 at 15:53
  • \$\begingroup\$ 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 \$\endgroup\$
    – DerStrom8
    Commented Apr 8, 2017 at 21:58

1 Answer 1

Reset to default
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.