DrizzlingBytes is a way to provide over-the-air (OTA) device firmware update (DFU) for MSP430-based systems.

In this implementation, an ESP32 (SoC) acts as a Hosting Device, managing and downloading new firmware available from Firebase Storage and then programming the target MSP430 (MCU).

Access to the target's embedded memory is via the Bootstrap Loader (BSL), sometimes just called a "bootloader", available natively on MSP430 microcontrollers.

The MSP430 bootstrap loader does not start automatically; a special sequence is required on the RST/NMI and TEST pins, and then, a serial communication to the target becomes available through BSL. The entire process for using this feature can be found in Texas Instruments SLAA096B documentation, used as a reference in this implementation.

Briefly, the process is as follows:

Put the MSP430 in Bootstrap Loader mode by the following invocation process:

From this point, the target is ready to communicate with the host. There are two ways to do this: from I2C or UART protocols. In this case, UART is the choice. The necessary settings for the peripheral are:

And then writing the BSL commands as needed. The possibilities are:

All commands must be transmitted according to the BSL protocol shown below:

Then, after performing the desired memory accesses, set the target to normal mode operation again, exiting BSL mode:

All tests and validations were performed with the following circuit:

As shown in the schematic above, the target MSP430 used for testing is an MSP430FR4133. In order to have a clear visual representation of whether or not the target firmware has been updated, two firmware versions have been pre-compiled: Slow_Blinky and Fast_Blinky.

The source code used to produce these files can be viewed below and Code Composer Studio was used has Integrated Development Environment (IDE).

#include <msp430.h>

#define FAST 100000
#define SLOW 1000000
#define LED BIT7

void main(void) {
    WDTCTL = WDTPW | WDTHOLD;

    P2OUT &= ~LED;
    P2DIR |= LED;

    PM5CTL0 &= ~LOCKLPM5;

    while (1) {
        P2OUT ^= LED;
        __delay_cycles(SLOW);
    }
}

The version that makes the LED blink slowly was flashed to the MCU and the version that makes it blink faster was uploaded in Firebase Storage. That way, if the ESP32 is able to successfully download and update the target, it will be easily noticeable by the blinky frequency of the LED.

Once the circuit is powered up, the ESP32 downloads the firmware from Firebase and starts the MSP430 programming process. The result of the BSL invocation as well as the periods of each pulse can be seen below:

If all goes well, the communication between HOST and TARGET can be seen through the UART (Docklight used as serial terminal):

Organizing and synchronizing the submissions and responses between the parties for better visualization, we have:

The assembled circuit used for the tests:

Simplified Code Example

This is a simplified code snippet to show the main functions of the MSP430 library from the Drizzling Bytes project. Check the /Examples directory for a complete implementation.

#define CLOUD_FIRMWARE_ADDRESS "new/firmware.txt"
#define SPIFFS_FIRMWARE_ADDRESS "download/firmware.txt"

MSP430 BSL(ESP32_GPIO_RESET_PIN, ESP32_GPIO_TEST_PIN, Serial2, SPIFFS_FIRMWARE_ADDRESS);

FirebaseStorage OTA(STORAGE_BUCKET_ADDRESS, FIREBASE_FIRMWARE_ADDRESS, SPIFFS_FIRMWARE_ADDRESS);

void setup() {
	OTA.download_firmware_and_store_in_spiffs();

	BSL.load_firmware_from_spiffs();

	BSL.invoke_target_bsl_mode_operation();

	BSL.write_default_password();

	BSL.write_firmware();

	BSL.invoke_target_normal_mode_operation();
}

Contributing

0. Give this project a ⭐
1. Create an issue and describe your idea.
2. Fork it.
3. Create your feature branch (git checkout -b my-new-feature).
4. Commit your changes (git commit -a -m "Added feature title").
5. Publish the branch (git push origin my-new-feature).
6. Create a new pull request.
7. Done! ✔️