Msp430 Serial Bootloader

• Msp430 Serial Bootloader Update

It isn’t much trouble programming one of TI’s MSP430 chips, but outside of the official Flash Emulation Tool, TI doesn’t make programming one of these microcontrollers cheap. The most common way of programming an MSP430 is using a Launchpad Dev board, and Vicente.The MSP430 series of chips can be programmed through JTAG or Spy-By-Wire, and the official, professional engineering tool from TI for these chips. Those of us with more sense than money have another option – use one of the TI Launchpad dev boards as an MSP430 programmer.Vicente’s project uses the MSP430G2 Launchpad, with just a few wires going to the proper connector found in the official programmer from TI. There are a few limitations; the programmer only works at 3.6V, so programming 1.8V devices might not be a good idea. Also, it only works with Spy-By-Wire and no JTAG support is available.

Still, it’s a great looking project, and does exactly what it’s designed to.Posted in Tagged, Post navigation. Don’t need to be so harsh. I never said that it was something new. But it can be interesting for someone starting with the MSP430G line. I think there should be projects for all the audiences.In another words, if you know that you can program MCUs outside the Launchpad board and you know how to do that you don’t need that article.

For the people startings with MCUs in the MSP430G line that have a launchpad board it can give some hints about how to program their projects in a ISP way.Aside from that I also don’t know how the posts are selected on Hack a Day. When I submitted my STM32F3 Gizmo that programs the STM32F3 Discovery board in a multitasking forth like languaje in console mode using an USB serial port it didn’t get trough altough it is a much more complex project. $115 for a tool that you’ll use over and over isn’t a lot to be honest. Consider how much time this guy put into building his tool and what it can do in comparison to the TI tool. If this was about a $500 JTAG pod from Seggar vs an FTDI based dongle that works with OpenOCD then I think I would agree more with the article copy; “Those of us with more sense than money have another option”. $115 is a few hours of pay for me.

And having the TI tool that can do more and works with more parts could potentially save me hours of frustration working with hacked up stuff. So just ordering the TI tool from Digikey would make a lot of “sense”. If you are playing with ARM chips, you really should use better tools. There are plenty of $20 and below development boards with onboard SWDIO based debuggers from the chip vendors and often with connectors for external board. Unfortunately the debuggers are specifically targeted to their ARM families, but at least that’ll get you started.They are supported by OpenOCD and IDE.

They will let you do hardware debugging. From my limited experiences with ARM that they have a lot more complicated beasts. Your core can ended up in hardfault or other exception handler if you forget to turn on gating clock or other silly things in your startup code etc. UART is not going to help you when the core crashes, but you can still look at the stacks, memory and peripheral setup if you use hardware debugging. SWDIO is the low pin count alternative to JTAG and is used on all the Cortex M series these days. No, thanksI like the MSP340 for its simplicity and the fact that they are available in DIP footprints.They are also very low power if used well.Never play an ace when a 2 is enough.For ARM Cortex I typically use the Discovery line of boards although I also have some Nucleo boards too.

In this case I use ChibiOS/RT to do multitasking and program using a custom configured Eclipse IDE that runs GNUARM and OpenOCD.In a time when hardware debugging is so cheap and easy It puzzles me the use of Bootloaders. I know they are usefull, but for developing I don’t like them. Good to know about them. I didn’t know there are a lot of Cortex with DIP packaging and searching I can only find some NXPs. In fact, the LPC810 looks interesting.Don’t like adaptors when I need DIP.Time is scarce so I have focused on ST for the ARM Cortex line because their budget boards are quite interesting. Some freescale are interesting too.I leave to MSP430 the low profile projects.

They are so low powerOff course M0 and M0+ are targeting low end 8 and 16 bits.Now I have got some Cypress SOCs that feature Cortex M0+They are an interesting blend of MCU and Programmable LogicToo many MCUs and too little time: (. That’s a seriously amateur piece of work. As others have said there are better Launchpads to start from. I’d go for the FR5969 as that programs all (I think) MSP430s has the awesome EnergyTrace functionality built into the FET. At the very least, cut that Launchpad before you mount it in a huge fugly case. They’re even marked clearly so you can see what’s the FET part and what’s the target.Other options are the tiny EZ430-F2013.

TI gave these away free as a promo once. Even the full MSP-FET was on a half price offer until recently.Of course, as the ezFET board files are freely available you could even make your own FET like this one from Greeg over on 43oh.

MUSIC PLAYING Hello, everyone. Welcome to the first training about the MSP bootloader. In this training, we would like to cover the high-level concepts of the MSP bootloader. The MSP bootloader provides a method for writing a program to the MSP device memory. Before we examine the term 'bootloader' itself, let's take a quick look at how the MSP430 and MSP432 applications are developed.Since microcontrollers are programmable devices, the software developer has the ability to develop an application to the microcontroller's memory.

In order to build an application to run on MSP microcontrollers, you can choose from a variety of toolsets, often called Integrated Development Environments, or IDEs. The most common IDEs today include Code Composer Studio and IAR Embedded Workbench.The application is usually written in C code, which is turned into a binary image by the C compiler that is a part of the selected IDE.

The binary image is the actual file that can be downloaded into the MSP. There are two options for how you can download the binary image to a MSP device.As shown here, one option is called JTAG or SBW. For MSP430 or JTAG, SWD for MSP432. The second option is called the bootloader, or BSL for short. The major difference between these two programming methods is the protocol use to transfer the binary image to the MSP.The JTAG method uses the debugging port to transfer the image. This is the protocol used by the IDE when debugging a program. The IDE uses a debugger probe, such as the MSP-FET, to read and write the memory in the device.

This protocol also allows the developer to set breakpoints, single step through the program, as well as other various debugging techniques.JTAG is a debug and a test protocol that is used by most vendors. Since JTAG comprises four or five pins, some users prefer the lighter Spy Bi-Wire, or SBW, or Serial Wire Debug- SWD- versions of the debug protocol. From now on, we will refer to this simply as debugger communication.Then why do we need the alternative bootloader protocol for transferring a binary image to the MSP? This is often referred when no debugging features are needed, but rather, when the user wants to simply download from our image to the device. This is often the case for field firmware updates or on a production line. In other words, the bootloader covers simpler hardware and software configuration.

For example, the bootloader only requires a simple serial connection, while debug communication needs a debug probe.The bootloader term has a different definition depending on whether you are using a microprocessor or a microcontroller, like the MSP. In both cases, the bootloader usually refers to a small program that is stored in the device's RAM memory. Unlike microcontrollers, though, microprocessors do not have on-chip nonvolatile memory where they can store the application programs.Instead, the application is often kept in slower off-chip memories, such as external flash.

Then, every time when the microprocessor is booted up- that is, when it's powered up- its bootloader reads the application code from the slower extended nonvolatile memory and writes it to faster RAM memory, such as the external SRAM or fast external DDR memory. From the microcontroller perspective, such as MSP430, the bootloader is used to write the application code, that is, firmware, to the nonvolatile memory of the device.This is done infrequently- only during the production phase or when a firmware update is required. Because microcontrollers include nonvolatile memory, such as Flash or FRAM, once the device is programmed, the application continues to reside there indefinitely.In the past, the bootloader was often referred to as MSP430 bootstrap loader, or BSL for short. Nowadays, it's more common to simply use the term bootloader, though the BSL abbreviation is still used since it's convenient. From this point on in this training module, we will use the terms bootloader and BSL interchangeably.Looking at the outline for our training, we have already covered the overview section. The next sections will cover the bootloader components, a simple demonstration, and finally, the summary.

As mentioned earlier, BSL is one of the methods we can use for downloading application code to the MSP microcontrollers.The basic components required for this process include firmware image. Using the software build tools such as Code Composer Studio, you need to create a binary firmware image for your application. BSL Scripter. We need a PC software program that can transfer the firmware image over a serial port to the MSP device. In this training, we use INAUDIBLE application provided by Texas Instruments. Additional tools, such as MSP-GANG Programmer can also be used to perform BSL programming, but they will not be covered during this training module.MSP-BSL Rocket.

Since most personal computers do not include a serial port anymore, we need some way to convert USB commands into a simple serial communication protocol, such as UART. The low cost MSP-BSL Rocket is a simple tool that handles the USB to serial conversion. Once again, there are other hardware tools that provide BSL programming, such as the MSP-FET and the MSP-GANG. Last, but not least, is the BSL code that resides inside the MSP microcontroller.BSL refers to the bootloader code that recites in every MSP device.

Normally, after the device is restarted or powered up, the user's application is executed. To write or update the application firmware, you can initiate the bootloader by using a specific startup sequence. Since the sequence fires by MSP device generation, we don't cover those details during this BSL introduction module.In fact, for our demo, the BSL Scripter and MSP-BSL Rocket handle all these details for us. Once the BSL is invoked, we can start using BSL commands to download new firmware to the device. More specifically, we communicate with the BSL by issuing commands and then evaluating results.For example, we begin by sending a command from the host to the BSL code running on the MSP device. The BSL interprets the command and then sends back the execution status.

The status indicates whether the command was successfully implemented or if an error occurred. In general, the BSL code provides a few primary capabilities- write memory, erase the memory, and read the memory.Other than providing memory access, BSL often provides a means of configuring the security features available on a device. Configuring the security features will be covered in a future training module. Next, let's jump back over the left side of our diagram.The firmware image consists of a complete MSP microcontroller application.

The BSL Scripter tool reads the firmware from this image file and writes it to the serial port. The BSL Scripter expects the firmware image to be in a TI TXT format.

Let's say most IDEs do not create this file format by default. Therefore, you will need to modify your project build options to create this format.As a little background, there are many binary file formats used throughout the industry. Most users only need two of them- one for debugging and the other for firmware updates.

As an example, when building your project, CCS automatically writes your program into a debug file format with the.out file extension. A project build option, shown later, tells CCS to also write your program into the binary TI TXT file format. This option can create both file formats every time the project is built.BSL Scripter is a command and application that is available for Windows, Linux, and Mac OS X platforms. It is an open source application that is available from TI website.

We will include a link to this program in the summary at the end of this training.As stated previously, the MSP-BSL code accept commands such as memory reads and writes. Most users group the necessary commands which are needed to perform an action, like a firmware update into a script. The BSL Scripter tool reads the user's script and sends the commands over the serial communication port.In general, the process starts with the BSL invocation to access the device. This is followed by issuing the list of BSL commands found in the provided script. Commonly, the commands we are executing are writing the firmware image that we just talked about to the device. Besides sending commands to write the firmware to the device, the BSL Scripter tool also has the ability to interpret the responses from the BSL indicating whether the command was successfully executed by the BSL or not.The BSL Scripter is probably the most common tool used for BSL firmware updates.

But remember, there are other tools, such as MSP-GANG, which can perform these actions. In fact, the MSP-GANG is unique that it offers both a software interface, replacing the BSL Scripter, as well as a hardware tool which can be used in place of the MSP-BSL Rocket tool, which we examine next.BSL communicates using one of the supported serial protocols. Supported protocol differs by device.

Please refer to the device datasheet for details. The MSP-BSL Rocket translates USB protocol into the appropriate serial protocol.

Once again, this is required since most PCs don't include a serial port nowadays.Along with a USB connector on one end of the MSP-BSL Rocket, the other end includes a 10-pin BSL connector. This 10-pin connector conveniently fits into a socket provided on the MSP target circuit boards.

The target circuit boards are an easy way to connect the MSP microcontroller to your own hardware during early software development.The MSP-BSL Rocket is just one of the ways to make a BSL serial connection. Remember from the previous slide, the MSP-GANG can also provide this capability. Finally, it's worth mentioning that while the MSP-FET costs a bit more than the MSP-BSL Rocket, along with BSL capability, it also supports a wide range of debugging capability via JTAG, Spy Bi-Wire, and Serial Wire Debug.Now that we've discussed what function the BSL provides, let's go through a couple of examples so that we can show how firmware programming is accomplished using the BSL bootloader. In our first example, we will use the BSL Scripter application to download the blink LED program into the MSP430 F6459. The MSP-BSL Rocket providing a serial connection from our PC to the MSP-TS430PZ100C target circuit board, which conveniently holds our F6459 device, using a Zero Insertion Force socket, which can hold our F6459 device.By using CCS, we can prepare a blink firmware image application.

Finally, we also need a simple script of BSL commands in order to download the firmware. When using a target circuit board, the MSP-BSL Rocket can be connected directly. The other end of the rocket is connected via a USB connector to our PC.Now, let's run the BSL Scripter. Notice how the BSL Scripter opens the communication with the BSL via MSP-BSL Rocket, then invokes the BSL. Before we can communicate with the BSL, we first need to unlock it.

Since our new device is still empty, we send the default password. And the BSL response is password is correct.With the BSL unlocked, we send the blink LED application. BSL Scripter responds by showing the number of bytes that are written to the memory and the elapsed time. After the downloading is done, we just need to power cycle to see the light is blinking.The second demo uses MSP430FR4133 LaunchPad. Since the launchpad has a built-in debug interface, we don't see many people using BSL with a launchpad. It's more common to use BSL with the target circuit courts, as shown in our first demo.

But the LCD on this launchpad makes it really easy to visually differentiate between the two different firmware images, which is the point of demo number 2.Unlike the target circuit board, the launchpad does not contain a BSL connector. We can get around this using jumper wires. Using CCS, we prepared two firmware images. First application shows the words 'HELLO' and 'WORLD' alternately on the LCD. To differentiate the two application firmware images, the second application uses the word 'MSP 430' and 'BSL' alternately.

Along with firmware images, we also need a script to download the firmware.As you can see, the hardware setup must be done manually between MSP-BSL Rocket and LaunchPad FR4133. For this device, the reset and test signals are used to invoke BSL mode.

Msp430 Serial Bootloader Update

We're using additional main connectors and jumper wires to connect the proper signals on the MSP-BSL Rocket to the appropriate pins found on the launchpad.The additional signals needed include the MSP430FR4133 UART RX/TX pins, as well as the power and ground pins. The table on this slide summarizes all of the required connections.

Just like with the first target circuit board example, we need the following steps. Now let's run the BSL Scripter.Notice how the BSL Scripter opens the communication with the BSL via the MSP-BSL Rocket, then invokes the BSL. Before we can communicate with the BSL, we first need to unlock it. Since a new device is still empty, we sent the default password. And the BSL response is password is correct.With the BSL unlocked, we send the Hello World application. The BSL Scripter responds by showing the number of bytes that are written to the memory in the elapsed time. After the downloading is done, we just need to power cycle the device to see the text on the LCD display.Our second demo provides an example for updating the firmware on a device.

In this case, we will use the showbsl430 application so we can see via the LCD that a new firmware is running. In this case, using the default BSL password won't work because the device isn't empty. Instead, we would need to send the correct password which can be obtained from the showhelloworld program.With the correct password used in our new application, the remaining steps stays the same as before. The BSL Scripter opens communication with the BSL via the MSP-BSL Rocket and then invoke the BSL mode. We send the password. And if we use the correct one, the BSL response should be password is correct.The next step sends the showbsl430 application.

When completed, the BSL Scripter tool will show the number of bytes that are written to the memory and the time elapsed. After the updating process has completed, we reset the device and should see the new firmware running.From this training, we hope that you now understand the overall bootloader BSL concepts for the MSP microcontrollers. A key part of this training was for us to realize that the BSL bootloader is one of the methods we can use to write application firmware to MSP microcontrollers. While it does not offer debugging capability, it does provide a simple implementation for production programming, as well as in the field firmware updates.The BSL ecosystem consists of the BSL Scripter- PC application- a communication bridge, such as MSP-BSL Rocket, which translate the USB protocol into serial communication, and finally, the BSL code itself, which is found in our MSP devices. The BSL Scripter and MSP-BSL Rocket tools used in this training can be found at www.ti.com/tool/mspbsl. If there are any other questions or feedback regarding this training, please feel free to reach us at www.e2e.ti.com. Thank you for attending this video training.MUSIC PLAYINGDetails.

This is an overview of the MSP430 and MSP432 bootloaders, which are also referred to as the bootstrap loader or 'BSL'.Bootloaders are an essential part of a microcontroller's (MCU) development ecosystem. They are often used to perform production programming of the MCU, or may be used to perform device firmware updates.Starting out with the definition of a microcontroller bootloader, this video explains the essential steps in the bootloader procedure and then ends with a couple examples which demonstrate the process. This training includes a demo showing BSL firmware updates to a LaunchPad and Target Socket Board using the BSL Rocket. Arrow-top close delete download menu search sortingArrows zoom-in zoom-out arrow-down arrow-up arrowCircle-left arrowCircle-right blockDiagram calculator calendar chatBubble-double chatBubble-person chatBubble-single checkmark-circle chevron-down chevron-left chevron-right chevron-up chip clipboard close-circle crossReference dash document-generic document-pdfAcrobat document-web evaluationModule globe historyClock info-circle list lock mail myTI onlineDataSheet person phone question-circle referenceDesign shoppingCart star tools videos warning wiki.