Jump to content
43oh

Speeding up the Launchpad UART


Recommended Posts

I was wondering if anyone has worked on speeding up the launchpad uart? As near as I can tell, the reason that it is limited to 9600 baud is because the BSL is limited to 9600 baud. IE in order to upgrade the firmware for the MSP430F16x the baud rate has to be 9600. So if you use the FET pins at the top of the board to reprogram the MSP430G16x, the baud can be changed.

 

Note, it would seem to requires 3 code changes to do so, none of which are in friendly C coding.

The raw assembly dump is at http://processors.wiki.ti.com/index.php ... d_firmware

 

It would require finding the baud settings for both UARTS in the launchpad and changing them.

 

It also requires changing the baudrate setting for the TUSB IC - which I believe is actually stored in the MSP430G16x. As near as I can tell, the TUSB can only get it's baud settings from 2 places: either from the computer via the usb initialization or via I2C from EPROM. Since the TUSB I2C pin happens to be tied into an I2C pin of the MSP430G16x it makes sense that the MSP430 is acting as the EPROM device for the TUSB firmware.

Link to post
Share on other sites

The TUSB3410 firmware does the application UART - the F1612 is not involved at all. So you would have to modify the firmware for the TUSB3410 to increase the interrupt rate used for the bit-bang serial, program the 24LC128 EEPROM (U5) that holds the firmware, and hope the higher interrupt rate does not interfere with the main line code.

Link to post
Share on other sites
  • 3 weeks later...
I'm sure it is on the EEPROM.. however debugging this will be a pain and a number or bricked LPs

 

Or easy and just use someone else's work:

http://sourceforge.net/mailarchive/foru ... dfet-devel

 

He worked out how to turn a Launchpad into a Goodfet.

Of particular note is:

void disable_eeprom()
{
// P3.1 SDA
// P3.3 SCL
       P3OUT &= ~((1<<1)|(1<<3));
       P3DIR |= (1<<1)|(1<<3);
}
// TI lauchpad has 12 Mhz X-tal on XT2 which also is the base clock
for the TUSB34010
void enable_tusb3410()
{
       disable_eeprom();       // we can load software from USB
// generate 12 Nhz clock for TUSB3410
       P5SEL |= (1<<5);      // P5.5 is SMCLK to TUSG3410
       P5DIR |= (1<<5);      // P5.5 is output
// release reset for TUSB3410
       P4DIR &= ~(1<<6);       // release reset to TUSB3410
}

 

If I follow this correctly, the eprom gets it's clock cycle from the MSP430F1612 over P3.3 - so he disabled the entire P3 port so the EPROM doesn't run. Then he resets the TUSB3410 - which will now download it's firmware from the linux host device instead - which happens to be a very basic default firmware set to act as a 115,000/8/n/1 usb to uart bridge.

 

I'm going to have to give this a try and see if I can get it running. At 115k I can get a lot more readings from my scope!

Link to post
Share on other sites
I'd definitely try this out if someone goes first :) I have a couple of early Rev LP's I'd be willing to do this on.

 

 

I'll give it a shot and post how it worked out... After digging through the code a bit, I found Peter was extremely generous and he included the option of using a GoodfetTILaunchpad for pure serial passthrough by just setting a jumper across 2 of the programming pins. Heck, even if it goes nowhere I recommend digging into his code just because he so clearly documents the pinouts of the top portion of the launchpad - including some ideas on which unused pins look like their most easily modded.

Link to post
Share on other sites
Disabling the EEPROM by any method will just allow the TUSB to be a ACM CDC device to the F1612, it doesn't magically make the app UART faster, in fact it disables it entirely.

 

Well, correct that it doesn't magically make it a serial passthrough device - that comes from the beuaty of how the thing works...though this process may only work on Linux.

 

When the TUSB device comes up, the first thing it does it tries to grab it's firmware from I2C[in theory an EPROM, but it could be anything that pretends to be an EPROM]. Assuming it finds a firmware, it will then load that firmware where the baudrate is configured.

 

If it does not find a firmware there, then it falls back to whatever defaults it has and will accept firmware from the host computer via usb. This is one the basic 'magic' functions of usb - when a usb device powers up, it will send it's VendorId and ProductId to the computer. The computer will then load the "driver" associated with that VendorId/ProductId. The driver MAY contain firmware code for the device - allowing an upgraded computer side driver to upgrade the device it communicates with automagically.

 

Now, any usb device at the other end will ignore any attempts to send it new firmware from the PC unless it follows the 'rules'. In the case of TI's USB chip the rule is "If I don't have a firmware from I2C, accept the firmware from the PC".

 

Once the firmware loads, the usb chip will do a soft reset and all it's new functionality is in place.

 

In the case of the TUSB linux ships with default firmware to configure it as a usb to serial bridge running at 115k/8/n/1 - so by disabling the eprom you force it to use the firmware linux happens to be sitting on....unless you want to have some fun and write a truly custom firmware. As a sidenote, the TUSB chip is an 8051 processor and it has 4 GPIO pins on it in addition to all the pre-defined stuff - so you can have all sorts of fun like copying the input/output streams to a second set of pins...of course your going to need to do some fancy wiring to get at them.

 

I'm not sure if the Windows drivers from TI include the default firmware used by nearly everone to give it 115k....I guess once I finish flashing it I'll have a better idea. Right now I'm in the process of getting a virtualbox setup with mspgcc so I can compile the goodfet firmware and either brick one of my launchpads or free it. :-)

Link to post
Share on other sites

If it does not find a firmware there, then it falls back to whatever defaults it has and will accept firmware from the host computer via usb.

 

If it finds nothing valid in EEPROM, then it uses the default CDC ACM code. Using the USB bootloader for your own code requires a few specific valid records in EEPROM (VID/PID, descriptors and such). This behavior is not well documented.

Link to post
Share on other sites
I was wondering if anyone has worked on speeding up the launchpad uart? As near as I can tell, the reason that it is limited to 9600 baud is because the BSL is limited to 9600 baud. IE in order to upgrade the firmware for the MSP430F16x the baud rate has to be 9600. So if you use the FET pins at the top of the board to reprogram the MSP430G16x, the baud can be changed.

 

Just to be clear, there's nothing wrong in reverse engineering and digging in machine code if this make someone happy. But why loosing time on MSP430F16x (because of launchpad)? There is MSP430F510 with USB and (at least 500kbps) uart, on 25Mhz off course.

 

I am definitely for... If it's working good don't change nothing (even if the base is from stone age). But, anyway don't understand TI. Why they didn't change the base for debugging/programming tools from TUSB + I2CMEM + MSP430F16x combination to MSP430F5529.

Link to post
Share on other sites

It is a legacy design derived from the MSP-FET430UIF. The chips used where state-of-the art at the time. It was a big upgrade from the parallel port based MSP-FET430PIF.

 

Pictures of the Wolverine seem to show a new FET. Hopefully Stellaris, F5000 or FTDI based.

 

It would be great if they created a universal programmer/debugger for all TI micros based on a low end Stellaris chip. I would not be surprised if they are working on that. The Stellaris launchpad broke tradition by using a second Stellaris chip (identical to the first) for ICDI. The older dev boards typically used FTDI + CPLD.

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...