Data transfer to the PC via the UART-USB back channel (LaunchPad control using PC)

The backchannel UART is a fake device that works through the programmin gpart of the LaunchPad. It is not advised to use it in any project, only for debug outputs when evaluating the MSP. It is not available without the programming toolchain installed and the MSP attached to the LaunchPad hardware. For any project that will include its own PCB later, this functionality will not be available later.

So for a reliable (and independent) connection, you'll need to attach a level shifter (such as the MAX232 or its brethren) to the MSP and connect it to a serial port (or maybe an USB-to-serial adapter, if the PC has no serial port anymore).

so cant we connect MSP430 directly with our PC using UART as they have done in their capacitive touch screen. They have made several applications like mediapad and touchscreen which interacts through USB using UART.

I was thinking of any such connection, if , possible.

Thanks for suggestions

Yes, it is possible.

The "Emulation" part of the LaunchPad  has a TUSB3410 chip that does what you want (in a limited way). This chip emulates two "com ports". One is used by the MSP430F1612 chip to handle JTAG SBW. The other one is the "back channel" you referred to.

On the PC side, this connection shows up in the Device Manager as a virtual com port. Programs like Hyperterminal can be used to access it.

On the MSP430G2xx side, the 3V logic signals TXD and RXD (as so marked on the PCB) are available. They are normally connected to Pin#3 and Pin#4 respectively. All you need to do is have the firmware use those two pins to do serial communication at 9.6kb/s or slower.

Thanks..

Will let you know in case i face problem in implementing what you said 

old_cow_yellow said:

at 9.6kb/s or slower

Anyway, this way of sending data is only available as long as the LaunchPad PCB is used. And cannot be easily copied to an own PCB. It's a quick and easy dead-end.

Jens-Michael Gross said:

Since the TUSB is not reprogrammed (or programmable) in any way by the target MSP or the PC software...

Just for clarification, the PC owns that serial port as if it were installed on its own motherboard.  It just happens to be installed over USB.  The PC can configure it however it chooses, and it is a very flexible device.  (If it's not obvious, I happen to think the TUSB3410 is a very nice device.)

Jens-Michael Gross said:

...cannot be easily copied to an own PCB. It's a quick and easy dead-end.

Have to disagree here, too.  Lots of MCU-based devices have USB communication to a PC through TUSB3410 or similar device.  The MCU needs only a UART, but the final product appears to have USB connectivity.  The PC driver decides whether to treat it as a basic serial port (COMx) or as a more mature device.  I don't see it as a dead-end.

FYI - The 9600 baud limit is imposed here because the '2452 is using a Timer UART, not a USCI.

Jeff

Jeff Tenney said:

...

FYI - The 9600 baud limit is imposed here because the '2452 is using a Timer UART, not a USCI.

...

I do not think that is the real reason. A MSP430 Timer UART can support 115300 b/s. Also G2xx3 has hardware UART.

On the other hand, the TUSB3410 is probably using bit-banging on P3.0 and P3.1 for the "back channel". The 9600 b/s limit is probably cause by that.

-- OCY

old_cow_yellow said:

On the other hand, the TUSB3410 is probably using bit-banging on P3.0 and P3.1 for the "back channel". The 9600 b/s limit is probably cause by that.

I agree with Jeff that the TUSB is a nice device, yet adding it to an ultra-low-cost  G2 chip in a production project is, well, like implementing a solar cell to conserve power and then mounting a light bulb above it to make it work.

Taking an MSP with internal USB is much cheaper, lower power and offers way, way more possibilities.

Oh, sorry guys, I didn't understand the back-channel implementation.

old_cow_yellow said:

A MSP430 Timer UART can support 115200 b/s.

I'm with you on that.  Folks using 1 MHz MCLK/SMCLK probably shouldn't go higher than 9600 baud.  But folks using 16 MHz MCLK/SMCLK can use 115200 baud, and I would think even 230400 baud should work if the application code doesn't ever mask interrupts or communicates only half duplex.

Jeff

Jeff Tenney said:

Folks using 1 MHz MCLK/SMCLK probably shouldn't go higher than 9600 baud.

However, if you have 1 MHz crystal, 115200 shouldn't be a problem. The biggest problem here would be to stuff the hardware and fetch the incoming data :)

JMG - the limitations I mentioned were strictly for the Timer UART.  Devices with hardware UART can do much better (~10 times better at least).

We also have a 1611 system doing 115200 from the DCO.  We "measure" the DCO speed before configuring the UART, and then we use the UART at 115200 for a few minutes.  As long as we end up with a BR divisor of at least 23, it is solid as a rock.  So we're OK with a minimum required DCO of only 115200 * 23 = 2.7 MHz.  We use a 32768 Hz watch crystal to make the DCO "measurement".  I've read some of your posts where you discuss a similar approach, and it works very nicely.

Jeff

Jeff Tenney said:

JMG - the limitations I mentioned were strictly for the Timer UART.

Jeff Tenney said:

Devices with hardware UART can do much better (~10 times better at least)

However, 23 clock cycles for a bit should be still enough for a bit-banging UART. But in this case, I would leave the timer and do hand-optimized assembly code with counted execution cycles instead :)

Jens-Michael Gross said:

A BR of at least 23 means 3/4 of a DCO modulation cycle, which is good enough in mos tcases to eliminate or at least suppress the DCO jitter sufficiently. And with sort of a short-time calibration, yes, its fine.

Probably so.  All the same, we don't use DCO modulation on the 1611 for that very reason.  When you're measuring the DCO rate instead of counting on it to be close to a specific target, you have the luxury off turning of the modulator.

Jeff

96.875% of the time (i.e., 31/32 of the time), the DCOCLK has a 8% "shack". But this shack has a periodicity no longer than 32 DCOCLKs. Thus I usually FLL DCOCLK to 14.7456 MHz and can use it to generate baud-rate up to 460.8 k/b without any shack. 

OCY - Exactly why I really like the 5xx!  I use that same DCOCLK configuration, and I use DCOCLKDIV divided by 2, which is default anyway.  The resulting clock rate of 7.3728 MHz are safely below 8 MHz for MCLK and SMCLK, allowing 1.8V operation, also default.

Jeff

Jeff - When I use firmware FLL, I use 32768/16 as reference and try to make DCOCLK/7200 to match that reference. Note that 7200 is divisible by 32.

If you use the hardware FLL in 5xx to do the same, I think you need to set the FLL prescaler D to 8. Thus DCOCLKDIV will be 1.8432 MHz. This is because the divider (N+1) cannot be set to 7200 as desired. So you use 8*900=7200 instead.

OCY

OCY - I would have done a firmware FLL exactly the way you described.  However, my alternative to a firmware FLL was to write the code to adapt to whatever the frequency of the DCO was without modulation.  I ended up liking that solution better.

As for the hardware FLL, it follows your same approach but with 32768/1, not /16.  That corresponds to a change in your 7200 factor to 7200/16, or 450.  So the FLL is trying to make 32768 match DCO/450.  It's just like your approach but done at a higher integration frequency to allow for smaller divider values.

For my applications, I chose N = 225, D = 2, which causes DCOCLKDIV to be 7.3728 MHz.  I didn't use N = 450, D = 1, because it produces DCOCLKDIV @ 14.7456 MHz and I would have had to divide it in MCLK and SMCLK to get below 8 MHz (for 1.8V operation).  Either FLL configuration would work great though.

Jeff

Jeff Tenney said:

my alternative to a firmware FLL was to write the code to adapt to whatever the frequency of the DCO was without modulation.  I ended up liking that solution better.

Well, all of our devices have a high speed crystal (power is not an issue as they are intended to measure energy and send the result, so they already require much power and also have a constant power supply), so I prefer setting the clock system up to have a nice 1MHz ACLK (for the timer tick and others) and a 16MHz (S)MCLK for the highspeed stuff like SPI or UART. So DCO is a startup and fallback solution only (just let the device cry for help :) )

But if you have to live with the DCO, measuring it instead of adjusting it is surely a good way to have (temporary) exact timings.