• State
  • Locked Locked
  • Replies 17 replies
  • Subscribers 82 subscribers
  • Views 4279 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BSL pins of MSP430G2553 20-pin packages

Hannes Weisbach
Prodigy 90 points
Other Parts Discussed in Thread: MSP430G2553

Hi,

I have a MSP430G2553 device, which is listed as Launchpad-compatible. Launchpad-compatible devices use P1.1 and P1.2 as BSL-TX and BSL-RX, respectively. However in the MSP430G2553 datasheet (http://www.ti.com/lit/ds/symlink/msp430g2553.pdf), pins P1.1 and P1.5 are listed as BSL-TX and BSL-RX, which would make the device incompatible with the Launchpad platform. Which information is correct?

I would like to wire a USB-serial converter to the MSP for device programming and communication link. This would work rather nicely, if P1.1 and P1.2 were BSL-pins, because the coincide with USCI_A RX and TX pins. Additionally, I used P1.5 for the USCI_B clock output and USCI_B for SPI.

If someone could clear things up, I would appreciate it. Thanks.

  • 0
    TI__Genius 16205 points

    Hannes,

    Those pins switches to BSL pins when they are only in BSL mode. Once they leave the BSL mode, they act as a generic GPIO pin with the multiplexed functionality. In short, if you are not in BSL mode, you could absolutely use those pins just like a normal UART functionality.

    William

  • 0 in reply to William Goh
    Guru 58965 points

    As far as I know, there is no BSL ROM in that chip.

    William Goh said:

    Hannes,

    Those pins switches to BSL pins when they are only in BSL mode. Once they leave the BSL mode, they act as a generic GPIO pin with the multiplexed functionality. In short, if you are not in BSL mode, you could absolutely use those pins just like a normal UART functionality.

    William

    What is BSL mode in this context?

  • 0 in reply to old_cow_yellow
    Prodigy 90 points

    The Boostrap Loader is either located in ROM or in (a protected) Flash area. In this device, it is located in Flash, if I'm not mistaken.

  • 0 in reply to William Goh
    Prodigy 90 points

    William Goh said:

    Hannes,

    Those pins switches to BSL pins when they are only in BSL mode. Once they leave the BSL mode, they act as a generic GPIO pin with the multiplexed functionality. In short, if you are not in BSL mode, you could absolutely use those pins just like a normal UART functionality.

    William

    Thanks for clearing that up. But what are the actual BSL pins? P1.1 and P1.5 as listed in the datasheet or P1.1 and P1.2 as suggested by "Launchpad-compatibility"?

  • 0 in reply to old_cow_yellow
    TI__Genius 16205 points

    old_cow_yellow said:
    As far as I know, there is no BSL ROM in that chip.

    All MSP430G2xx3 has ROM BSL onboard. The older G2xx2 and G2xx1 does not.

    Regards,

    William

  • 0 in reply to Hannes Weisbach
    TI__Genius 16205 points

    Hannes,

    Hannes Weisbach said:
    But what are the actual BSL pins? P1.1 and P1.5 as listed in the datasheet or P1.1 and P1.2 as suggested by "Launchpad-compatibility"?

    The actual BSL pins are on P1.1 and P1.5. The datasheet would be the golden standard to follow. The launchpad-compatibility would need to be updated to reflect this device.

    Regards,

    William

  • 0 in reply to Hannes Weisbach
    Guru 58965 points

    My earlier comment was wrong.

    MSP430G2x53 and MSP430G2x13 chips probably do have BSL ROM which uses P1.1 and P1.5.

    Launchpad did not have BSL support in its design. But you can patch it up yourself.

  • 0 in reply to old_cow_yellow
    Prodigy 90 points

    Well, that's a shame. In that case my scheme to use one USB-serial converter for programming and communication does not work, because P1.5 is BSL RX and USCI_B clock output at the same time. For the programming everything would be alright. But when my application starts and uses USCI_B in SPI mode, the clock signal of P1.5 would collide with the data sent by the USB-serial converter. Unfortunately, the functions are not available at other pins.

  • 0 in reply to old_cow_yellow
    Prodigy 90 points

    old_cow_yellow said:

    My earlier comment was wrong.

    MSP430G2x53 and MSP430G2x13 chips probably do have BSL ROM which uses P1.1 and P1.5.

    Launchpad did not have BSL support in its design. But you can patch it up yourself.

    I did not know that. What programming procedure does the Launchpad use? Spy-By-Wire?

  • 0 in reply to Hannes Weisbach
    Prodigy 90 points

    I came across another problem. The data direction on the BSL pins is not clear to me. If a pin is labelled "BSL transmit" does that mean data is transmitted from the BSL-programmer to the device on that pin, or the device is sending data to the programmer?

  • 0 in reply to Hannes Weisbach
    TI__Genius 16205 points

    Hannes Weisbach said:
    What programming procedure does the Launchpad use? Spy-By-Wire?

    Yes it uses Spy-by-wire mode to program the launchpad devices.

  • 0 in reply to Hannes Weisbach
    TI__Genius 16205 points

    BSL Transmit would be the transmit pin from the MSP430 device out.

  • 0 in reply to William Goh
    Prodigy 90 points

    Ok, thanks. So, to use one serial converter for both, programming and application communication wiring get's a bit complicated.

    The transmit pin of the converter has to be connected to P1.1 for USCI_A RX and P1.5 for BSL receive. So far so good.

    The receive pin of the converter has to be connected to P1.2 for USCI_A TX and P1.1 for BSL transmit.

    This means P1.1 is connected to both, RX and TX of the serial converter, which obviously doesn't work. Is there another way to use one serial line for programming and communication than using a switch to route P1.1 (and appropriate High-Z control of P1.2 and P1.5)?

    Why aren't USCI RX/TX pins identical to BSL RX/TX pins? This would simplify things a lot.

  • 0 in reply to Hannes Weisbach
    Guru 227245 points

    Hannes Weisbach said:
    Why aren't USCI RX/TX pins identical to BSL RX/TX pins

    IMHO, the BSL is not using the USCI but rather the timer CCR unit pinsTA0.0 and TA0.1. And since it doesn't make sens to concentrate all hardware features on few pins, the timer CCR signals are not on the same pins as the USCI rx/tx pins are. Else it would be an either/or for using either USCI or timer outputs in your application. An even less desireable setup.

    Hannes Weisbach said:
    This means P1.1 is connected to both, RX and TX of the serial converter,

    I agree it's a bit unfortunate that the UCA0RXD is on P1.1
    The software UART on the smaller G2 devices (the ones that came with the original LaunchPad) had the two twisted. It looks like the BSL was compliant with these 8but not included with them) and for soem unknown reason the USCI in the 2xx3 has the two pins twistet, conflicting with the original LaunchPad layout and the BSL.
    Personally, I consider this a design bug in the 2xx3 device design. Unless someone can give me a good explanation why it was done this (incompatible and conflicting) way.
    I'm hoping for a MSP430G2553A device :)

  • 0 in reply to Hannes Weisbach
    Intellectual 290 points

    Hannes,

    Did you ever figure out a solution.  I have the same problem.  Did you just have to use a switch controlled by another GPIO Pin?  Or did you change MSP430s?

    Thanks,

    Tony

  • 0 in reply to Tony Megna
    Prodigy 90 points

    Hello Tony,

    I came up with a solution using three switches, controlled by the /RESET signal. So if the USB-serial converter asserted /RESET (and thus signalled it wanted to program the device) the switches would route RX and TX to the corresponding BSL-pins. Otherwise (/RESET unasserted) RX and TX are routed to the UART-pins of the MSP430. I have attached an PDF with the schematic.

    7041.msp430_bsl.pdf

    However, I have never put that idea into hardware, so I don't know if it actually works.

    Cheers,

    Hannes

  • 0 in reply to Hannes Weisbach
    Guru 227245 points
    I know it's an old thread, but while cleaning up my history, I came across this last post.
    Unfortunately, it won't work. I use a similar setup (not actually a flip) for teh ATMega, where the programmingis done while RST is low.
    However, on MSP. RST is only held low until the BSL entry sequence is ticked into TEST pin. Then RST is released. And the signal flip back into the wrong assignment.
    The only way would be to use the programmable I/O pins.
    The PEREN (CBUS3) output can be used for this. In normal operation, this pin signals whether the USB is active or in sleep state/not enumerated. Since during sleep, no data can be sent or received anyway, the firmware should check this signal and configure the UART pins only if this signal indicates active operation (and the switches are therefore in the position for UART data transfer). However, if this pin is configured for I/O, it can be used to signal 'sleep mode' even if active, before initiating the BSL transfer (the BSL will ignore its state anyway). After the programming, the pin function can be set back to normal. This will, however, require a configuration change of the FT232, which isn't trivial (normally, an FTDI-provided tool is used). Maybe it is easiert o permanently program one of the chips for I/O and then perform an /IO operation right before and after programmign that changes the pin state. I didn't look deeper into the possibilities of the FT232 I/O pins

**Attention** This is a public forum