• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 79 subscribers
  • Views 906 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F2274: Use the ez430-rf2500 serial port AND debug the code

frustrated
Intellectual 315 points
Part Number: MSP430F2274

If there's a way, it eludes me - so I figured I'd ask.  Is there a way that I can hijack the lone serial channel to interface to external project hardware and somehow still debug my code?  I imagine I could try to come up with some scheme of bit-banging to simulate a serial stream for the project interface, but I think I prefer to find another vendor's core with the appropriate features rather than get that primitive.

  • 0
    TI__Guru 56685 points
    Hello,

    This USB Dev stick had an Application UART connected from the MSP430 to the USB portion of the EVM. We would call this a backchannel UART on Launchpad eval boards.

    When plugged into a PC, you can open up a terminal to see the UART traffic. it is not used for debugging/programming so it can be used for your application. These are pins P3.4 and P3.5 on the device. Also pinned out on the MSP430 board is pins P3.0-P3.3 which correlate to USCIB0, which can be used for I2C or SPI to an external board (would still need I2C pullups). Please see Table 1, Table 2, and Figure 3 in Section 3 of the eZ430-RF2500 Dev Tool User Guide (http://www.ti.com/lit/slau227 )
  • 0 in reply to Jace H
    Intellectual 315 points

    Jace,

    First, thanks for the quick reply.  It's a little clearer to me, but I'm not quite there.  I do understand most of what you've said.  I've been using SPI interfaces (displays, flash, etc) on the 2500T for about 10 years.  I'm not a hardware guy, but I spent most of my time looking at the (slau227 - section 13) schematics before even considering posting.  I'm guessing that I erroneously assumed that the control of the target processor was being accomplished through the UART interface that the schematics show as being P3.4&P3.5 - exactly as you stated.  Assuming instead that breakpoint control is happening through pins 3 4 of the target interface connector, the UART would indeed not be involved in debugging.

    So at this point - from the viewpoint of schematics - it still appears if I hijack the P3.4 and P3.5 processor pins, there would be some type of signal collision unless I BREAK their connections to the "debugging" board.  Is that true?  Note that 'Table 2' - one of the references to which you pointed me - has parenthetical text for pins 1 & 6 that says "UART communication from 2274 to PC".  The other use seems to be ".... SPI mode".

    So..... In brief, 2 questions:

    Do I need to remove the asynch signaling connection to the target board to use the its UART as an interface to a 3rd piece of hardware?

    If so, will I still be able to debug?

  • 0 in reply to frustrated
    TI__Guru 56685 points
    Hello,

    Some background on MSP430 Communication modules. The USCI can be used in one or two modes. Which modes depend on the USCI Type , A or B. USCIA can be used in either UART Mode or SPI mode , while USCIB can be used in SPI or I2C mode. The debugger connection for this particular board has Test , RST , VCC, GND and UART TX/RX. Those UART pins could potentially be used in SPI mode, but is not setup this way on the debugger side of the connection. Let's ignore this for now as its not relevant. On the debugger side, the UART packets coming from the MSP430 are being translated into USB as a CDC COM Port. this is why you can open up a terminal on your PC and see the UART transmissions when plugged in.

    Now if you want to talk to external HW with this particular EVM, the easiest thing to do is to use SPI or I2C interface and use the USCIB you have access to as there are pinout points you can solder to already. (Again, you will still need pullup resistors for I2C external to this board.)

    If you need to use UART, then you may need to modify the connector in order to sever the UART connection to the debugger board. As you stated, there is a chance of collision. However, you maybe ok as typically the UART is not used from the debugger board unless you have a terminal open. The debugger board just takes what it receives and converts UART to USB or USB to UART to send back to the MSP430. If you never have transmissions from PC to MSP430 via terminal, then you may get away with just piggybacking onto the UART lines instead severing them.
  • 0 in reply to Jace H
    Intellectual 315 points

    Jace,

    I really appreciate you walking through this with me.  While I still have a lot of questions, I'm afraid at this point it boils down to "try and see".  I'm going to go ahead and mark this "Resolved".  I've not used this forum in awhile. Seemed to have a lot more participants back then.  I'm grateful you jumped in.

    As a parting thought (and a solicitation for you to share anything that crosses your mind), I wish I understood the "debugger" board better.  In fact, there's no reason to even run the UART lines to the Target board unless they had some function.  Not being able to find specific documentation on how the debugger hardware works, I'm left wondering whether it acts as some kind of hardware/software mux, terminating communication associated with debugging and passing others through. On the other hand, having spent may days/nights running the debugger, I can't think of any way to "insert" text I want sent to/through the target. Even then, the "host" would be the "other end" for my Target UART instead of the hardware I want interfaced.  I guess I'll start by severing the comm lines and seeing if everything else still works.

    Thanks again!

    Paul

  • 0 in reply to frustrated
    Guru 41995 points
    The main difference is that the 'back channel' serial port runs just fine - assuming a USB driver is available - even when the debugger is not running.
  • 0 in reply to Keith Barkley
    Intellectual 315 points

    Keith,

    Thanks for your comments. After reading documents associated with both the eZ430-RF2500 and eZ430-F2013 (which are claimed to be roughly interchangeable), I get the distinct impression that via some magic the debugger should work just fine while a host app talks with the target.  I would just feel better if the "Spy Bi-wire" theory of operation were spelled out somewhere.  Nonetheless, I THINK that whole subject is moot for my real concern.  I've convinced myself that - if I want to use the USCI for the target to talk to an attached device (directly connected to the target, NOT through the debug interface) - I need to "break" the Tx/Rx lines at H1 (the Target board header where J1 (on the debugger module) plugs in. This seems even MORE true if I want to use a different baud rate.

    Anyway, thanks again for your comments.

    Paul

**Attention** This is a public forum