Jump to content
43oh

LaunchPad's UART at more than 9600 baud ?


Recommended Posts

Hi everybody,

 

Launchpad "emulation" part provides a handy USB-to-serial converter going via pins TXD/RXD to MSP. I tried it and it works like a charm both under Windows and Linux at 1200, 2400, 4800 and 9600. However any attempt to set baud-rate to anything higher, like 19200 or 115200, no luck - i.e. it still works but only at 9600 instead of what was configured.

 

Did anyone seen this before or even (fingers crossed) know how to fix this?

 

Regards,

Alessandro.

Link to post
Share on other sites

as far as i know it is not possible to do this only with the hardware on the launchpad - the emulator only supports up to 9600 baud

 

but you can use an external UART-device like a nokia ca-42-cable or chips (i recommend ftdi-chips) - both are cheap and offer much higher speeds than the "on-board" - UART on the launchpad ;)

Link to post
Share on other sites

I've been working with this a lot the past few weeks. In fact, I should be positing the software UART Transmitter tutorial on my blog in the next few days. I'm interested in how you got the lower rates to work, because I have yet to do so. Here's what I figured from all my testing and experimenting:

 

In my experience, the LaunchPad can only do 9600 baud transmission. Note: It's not that it can transmit at up to 9600, it can only do 9600. I have yet to be successful at doing a lower rate, anyway.

 

I suspect the reason for this is that the TX/RX pins are wired to the F1xx MSP430 on the programmer side, which has other pins that connect to the TUSB chip. I suspect that this configuration is set to receive at 9600 baud in the programmer, rather than putting in any type of auto-baud detection.

 

As far as I've been able to tell, if you want any rate other than 9600 baud, you'll need to have an independent USB interface. If I'm wrong about the lower rates, and you can actually get them to work, then the programmer must be set to limit to 9600. I'm really confused, because you and others have said they have been able to do lower rates, but even using their code I can't get it to work at anything but 9600.

 

Edit: Looking again at your description, now I'm starting to wonder if it's possible that the 1xx chip can receive any rate, but then repeats that to the TUSB at 9600? I'll have to experiment some more...

Link to post
Share on other sites

Not sure about TUSB3410 itself. What I did is I removed TXD/RXD jumpers going to the target MSP and connected a known good USB-to-serial (FTDI), and than opened two terminal windows on PC, so that PC would be sending data to itself via both converters. Then I started trying different baud rates. Here are results:

- 1200,2400,4800 and 9600 works as intended;

- standard baudrates below that (600,300) are silently reassigned to 1200;

- standard baudrates above that (19200,38400,115200) are silently reassigned to 9600;

- any non-standard baudrate (i.e. 3600, 50000, 200000, etc) fails to open a port.

 

I guess that could be fixed by modifying firmware (either TUSB's which is in EEPROM, or MSP430F1612's), but it doesn't look like something that was already done. At least E2E forum at TI is stuffed with responses "no, this is not supported".

Link to post
Share on other sites

Ok, I've done some more experimenting, and come up with even more peculiar results.

 

Here's the setup I tested: FTDI FT232RL TX -> LP TX via the header between the emulation and target sides. Using two terminal windows (in linux), one connected to /dev/ttyUSB0 (FTDI), and the other to /dev/ttyACM0 (LP). I'm transmitting characters through the FTDI to the LP emulator, so the LP echoes the transmission back to the terminal.

 

Standard baud rates between 1200 and 9600 work as advertised.

Standard baud rates outside this range don't work at all.

Non-standard baud rates work as far down as 16 bps (including rates that are only 1 off of standard, eg. 301 bps or 599 bps.)

Non-standard baud rates work as high as 1,000,000 bps. (I didn't bother trying anything higher than that.)

 

I swapped the roles of the two board, with LP RX -> FTDI RX, and the results are the same.

 

This seems again different from your experience with this test, and it confuses me further why I'm unable to get software UART to work at anything other than 9600 bps. It can't be a clock inaccuracy, as I have a self-calibrated DCO, and at the very least I'd expect to get 4800 bps to work.

Link to post
Share on other sites

I have always assumed that the UART on the F1612 that connects to the target chip was running at a fixed speed of 9600 bps, and this is how the 9600 bps limit is enforced. Is this not the case? I learned recently that the USCI peripheral is capable of auto-baud detection, and I suppose this feature could be used on the F1612 if the serial peripheral on the F1xxx also supports autobaud. I suppose it would be easy enough to configure the target chip to something other than 9600 baud to check.

 

Any *other* speed settings are virtual, and do not have any meaning whatsoever.

Link to post
Share on other sites

Two ways to set the launchpad UART to be faster than 9600.

 

The Hard way:

Reprogram the MSP430F1. (But it might also be a hard limit inside the TUSB3410 8051 MCU. Also the program for the 8051 is stored on the EEPROM)

 

The Easy Way (I've done this before):

Cut the EEPROM's power or I2C data lines or simply remove it from the board. Cut the traces that connect the MSP430F1 and the TUSB3410. Do not remove the MSP430F1, as the TUSB3410 requires it for the clock source. Connect jumper wire to the RX and TX pins. Plug it in and it comes up as a TUSB3410 Virtual Com Port. Enjoy your 50 to 921.6 k baud rate. But it comes at the cost of a LP.

Link to post
Share on other sites
I have always assumed that the UART on the F1612 that connects to the target chip was running at a fixed speed of 9600 bps, and this is how the 9600 bps limit is enforced.

 

That was my assessment after playing with software UART code-- the only way I could get software UART to work through the TUSB chip was at 9600 bps. Plugging an FTDI chip directly to the emulator side (that is, jumpers are removed so the target MSP is not attached to TX/RX), I was able to get the above results in linux which says otherwise.

 

To add fuel to the fire, I've tried the test again in a Windows environment, using RealTerm. There, I was only able to get the 9600, 4800, 2400, and 1200 rates to work. No non-standard value in or out of that range work, and no standard values out of the range work. That may imply the driver in Windows itself cannot do anything but those four rates, but it doesn't explain why I can't get it to work with software UART from the MSP430 at those same rates.

 

Edit: I looked through the code carefully again, and finding nothing wrong gave it one more try. Now the code works at 9600, 4800, and 2400. The phase of the moon must be more favorable. :roll: Not sure why it won't work at 1200, at least. I'm starting to favor the theory that the Windows driver for the LaunchPad is limited to those four rates.

Link to post
Share on other sites

Reprogram the MSP430F1. (But it might also be a hard limit inside the TUSB3410 8051 MCU. Also the program for the 8051 is stored on the EEPROM)

 

If this were the case, programming speeds would also be limited to 9600 bps. I am almost certain the LP programs faster than this.

 

Cut the EEPROM's power or I2C data lines or simply remove it from the board. Cut the traces that connect the MSP430F1 and the TUSB3410. Do not remove the MSP430F1, as the TUSB3410 requires it for the clock source. Connect jumper wire to the RX and TX pins. Plug it in and it comes up as a TUSB3410 Virtual Com Port. Enjoy your 50 to 921.6 k baud rate. But it comes at the cost of a LP.

 

Now that's something I hadn't thought of. A SPDT switch (or equivalent logic) would let you direct the serial port to wherever you want it.

Link to post
Share on other sites

Testing with Windows 7 64 bit and HyperTerminal PE 6.3 using a 'scope to determine bit rate by measuring time between falling edges of ASCII character 'x'.

 

Bit rates tested: 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200

 

9600 bps

post-2341-135135524883_thumb.jpg

 

4800 bps

post-2341-135135524607_thumb.jpg

 

2400 bps

post-2341-1351355246_thumb.jpg

 

1200bps

post-2341-135135524591_thumb.jpg

 

All other tested bit rates did not change the bit rate - it was the same as the last supported bit rate.

 

It was often necessary to open the port several times to get the bit rate to change. I don't know if this a bug with the TI firmware or the Windows CDC ACM driver.

Link to post
Share on other sites
I have always assumed that the UART on the F1612 that connects to the target chip was running at a fixed speed of 9600 bps, and this is how the 9600 bps limit is enforced. Is this not the case?

 

The F1612 does not appear to be used for the application UART.

 

I connected a logic analyzer to all four serial data lines of the TUSB3410 chip - pins 17, 19, 31 and 32. The expected application UART activity was seen on pins 31 & 32 and there was no activity seen on pins 17 & 19 that are used for FET communication. This indicates that application UART data does not flow thru the F1612 and is done with bit-bang code on the 8051 core of the TUSB3410.

Link to post
Share on other sites

Grounding the SDA line of the TUSB3410 will prevent it from loading the Launchpad specific firmware in EEPROM. It will behave as if the EEPROM does not exist. The SDA line is easily accessible on the left side of R24.

 

Normal Launchpad configuration - HID for FET and COM port for application UART.

post-2341-13513552489_thumb.jpg

 

With SDA grounded - The ROM firmware in the TUSB3410 is used for standard CDC ACM protocol COM port.

post-2341-135135524895_thumb.jpg

 

Be aware that using the EEPROM-less configuration is not recommend by TI.

From slla170f:

4 No-EEPROM Implementations

It is possible to design a TUSB3410-based device that does not use an EEPROM. This solution reports

the default descriptors located in the bootcode, including the default VID/PID, and firmware is downloaded

from the host. However, doing so has two consequences:

 

Link to post
Share on other sites
  • 2 weeks later...

I finally figured out why the linux behavior was weird (ie. getting 10 Gbit baud rates): the screen program transparently changes your requested rate to something it can do, usually the next lowest, but if you're out of range completely it defaults to 9600.

 

Here's a list of the rates I confirmed work for the LaunchPad USB serial in Linux:

 


  • 75 4800
    110 9600
    150 19200
    200 38400
    300 57600
    600 115200
    1200 230400
    2400 460800

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...