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.

MSP430FR2355: Using MSP430 ROM based Bootloader BSL through RS485. Half duplex. Is it possible? Practical?

Part Number: MSP430FR2355
Other Parts Discussed in Thread: MSPBSL, MSP-FET

I'm designing a product that once produced, will only have access to half duplex RS485 pins for purposes of firmware updating.
Firmware updates are projected to be rare, maybe never, events.  The RS485 line will be properly biased, and two way communication is possible.

  • Is it possible to use the MSP430 ROM BSL over RS485?
    • How would I bench test that?
    • What happens to the ~RE and DE pins for controlling direction on the RS485 bus?

  • For a ROM based BSL, is there any chance of a custom initialization routine, to set the port pins up properly?
    If I jump the ROM based BSL from my code, will pins be reconfigured, or left alone?

  • How much FRAM space would it take to ignore the ROM based BSL, and compile a custom RS485 supporting version
  • Is the BSL Rocket able to do anything the MSP430EXP board can't?

  • How do I mass erase a bricked part?


Reference: https://www.ti.com/lit/an/slaa450g/slaa450g.pdf

Reference: https://www.ti.com/tool/MSPBSL#step3

T
he 430FR2355 appears to have a ROM based BSL, supporting UART, and calling the BSL from software.

  • Hey Bryce,

    SP430FR2355 ROM BSL does support updates over UART, but it assumes full-duplex system and uses the hardware USCI module which doesn't have any built-in abilities for half-duplex systems.  

    Because the BSL resides in ROM, you can no customize the existing BSL but you can bypass it and implement a customer BSL in FRAM.  The MSPBSL page you linked has all the related information and documentation.  For customizing for FRAM devices, you want to start with MSP430FRBoot.  It includes example projects BSL for UART based BSLs for a few devices in the MSP430FRxx families, and you can modify it from there.  This is also where you can get a sense of the memory size.  I just randomly opened the map files for one of the FR2433 UART MSPboot example and it looks like it's slightly under <1.5kB of FRAM.  

    To program over BSL, you need to invoke it and then handle the data transfer.  This can be done from a PC with the BSL Rocket, as well as the MSP-FET.  In the application, it's also often another host side MCU/MPU on the board.   However, I do not believe it's possible with the eZ-FET programmer that is found on the MSP430 Launchpads.  

    Hope this help.  

    JD

  • JD Crutchfield said:
    Hey Bryce,

    SP430FR2355 ROM BSL does support updates over UART, but it assumes full-duplex system and uses the hardware USCI module which doesn't have any built-in abilities for half-duplex systems.

    I've looked at the protocol, and the notes, and it's pretty clear that it's a half duplex protocol.
    If that's true, then it's down to controlling the RE and DE lines (switching directions on the half duplex bus, here RS485).

    Have any community members done this?  I'm happy enough recompiling the target side to match my particular hardware, but I'd rather not have to reinvent the PC side wheel. Possible?  A well traveled path?
    ---------------------

    If not, how do most projects handle field firmware updates, if the serial ports are used?

  • How would I customize the PC side of the RS485 link.

    Both sides need to control the data direction of the RS485 bus.

  • It depends on your hardware. I have a SparkFun board with an FTDI USB to serial chip on it. I had to do a little work to connect the signal from that chip intended for controlling a RS485 transmitter. But once I did that it just worked.

  • Bryce Nesbitt said:
    Both sides need to control the data direction of the RS485 bus.

    Further to David's comment:

    USB TO RS485 SERIAL CONVERTER CABLE Datasheet is a pre-made USB to RS485 cable which shows a RS485 transceiver connected to a FT232R, where the FT232R TXDEN signal is used to control the data direction.

    The FT232R USB UART IC Datasheet describes the TXDEN signal:

    Note that the TXDEN is activated 1 bit period before the start bit. TXDEN is deactivated at the same time as the stop bit. This is not configurable.

    Since the FT232R TXDEN signal is controlled by the hardware, that will be automatic rather than the software in the PC having to explicitly control the data direction of the RS485 bus.

    The Local Echo section in the USB TO RS485 SERIAL CONVERTER CABLE Datasheet also explains that the a bit can be changed in the FT232R EEPROM to select if the RS485 data transmitted is echoed back to the PC.

  • Chester Gillon said:
    Further to David's comment:

    USB TO RS485 SERIAL CONVERTER CABLE Datasheet i



    Ok, good.
    Does it work with the BSL?
    How does the target (not the PC) control direction on RS485?
    Is the BSL protocol Half Duplex ready?

  • I haven't attempted to use a RS485 based BSL myself, so can't answer all the questions.

    Bryce Nesbitt said:
    Is the BSL protocol Half Duplex ready?

    User’s Guide MSP430™ Flash Devices Bootloader (BSL) has:

    Bryce Nesbitt said:
    How does the target (not the PC) control direction on RS485?

    I am not aware of any hardware support in the eUSCI_A to have a pin automatically control the RS485 transmitter enable. Guess you would need a modified BSL which used a GPIO to enable the transmitter under software control. E.g. enable transmit prior to writing to UCAxTXBUF and disable transmit after the transmit buffer is empty.

  • Chester Gillon said:
    I am not aware of any hardware support in the eUSCI_A to have a pin automatically control the RS485 transmitter enable. Guess you would need a modified BSL which used a GPIO to enable the transmitter under software control. E.g. enable transmit prior to writing to UCAxTXBUF and disable transmit after the transmit buffer is empty.



    That's exactly the problem.  It's trivial in software to do the direction control on the target, except that the bootloader is in ROM.

    Automatic direction control external to the part is possible, but risky:

    https://www.electronicdesign.com/technologies/embedded-revolution/article/21806514/how-to-create-automatic-direction-control-for-rs485-interfaces

    "How to Create Automatic Direction Control for RS-485 Interfaces
    This article explores methodology for adding RS-485 capability to a PC’s RS-232 serial port by implementing automatic direction control. Ward Brown, Microchip MAY 16, 2018"

    Or using a 555 from TI App note TIDUBW6.

    Both these methods require the ROM bootloader and the PC side to delay a bit after each half duplex transaction, prior to sending.

**Attention** This is a public forum