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.

Boot Loader code example in C

Other Parts Discussed in Thread: MSP430FG477, CC430F6135


I am looking for updating my MSP430FG477 with a bootloader that I could load in my main flash. Starting from example code will be easier.

I know that I could use the BSL for updating my soft, but the design as been done and we can not change the hardware or patch, because we have too much unit. 

Here the code that I had already check, if you have other solution or advice , please let me know.

SLAA341 -- BootLoader in assembly (the difficulty was to mix C and assembly because I wanted to had some complex function in C to the bootloader)

SLAA450 -- BSL custom and standard code source for family MSP430F5XX and MSP430F6XX (different register too many change to do )

SLAA319a-- BSL PC side communication with BSL ( I need the BSL side for my MSP430FG477)

Thank for your time !!

Maxime Tardif

  • I need help on this too.  Did you find any?

  • From the BSL vector resides in 0C00h, and you enter the BSL by branching to the address contained in the vector; so if you make 0x0C00 a pointer and make a function call to address contained in that pointer you should be able to enter the BSL.


  • Thanks for replying.  That was fast :)

    I don't want to go to the bootloader from inside the cc430, I want to use the rst/tck/uart programming method described here to program it from embedded linux. You have to pull the reset low, toggle tck twice and then bring reset hi to start the bootloader, and talk to it with the 0x80, 0x10 commands and such. I'd like an example of that, and I haven't found it around anywhere.

  • Well, it depends on what embedded Linux environment you are using.  Something like the Beagleboard or Pandaboard has GPIO kernel drivers that you can access from userland; same for the UART/USART. Note these things usually run on 1.8V so you'd need a level shifter.

    I found this kernel documentation after a bit of Googling:

    Another way is to program the board bare-metal and access the GPIO registers directly, but I digress...

    (It should be similar for x86 Linux, but I'm not too familiar with low level x86 programming.)


  • I have that part covered, how to wiggle the pins.  I need the protocol for talking to the bootloader and getting it to update the application.

    Send 0x80

    Expect 0x90

    Send 0x10 //can I do this right away?

    Send AL //is this the address of boot loader space?  How do I know what to use?

    Send AM

    Send AU

    Expect ?

    Send D1 //can I move right into this?  Is this a hex file?  a d43?


    Send Dn

    Expect ?

    //Any cleanup/final commands?

    There are examples everywhere for reading, doing all the other stuff, but I never found one on how to do this.

  • It's just like a terminal command interpreter. You send 0x80, wait for ACK 0x90, then send the sequence of commands then wait for the reply.

    The sequence of commands are sent and received as data frames, per p13 of . Hence through the UART port (eg /dev/ttyS1) you first send the SYNC 0x80, then wait for 0x90, then send the data frame (8-bytes header, followed by optional data bytes, then 2 bytes checksum). The BSL then sends ACK followed by its own data frame (if requested).

    The data bytes are raw hex so you'd need to read and interpret the TI/MSP430-txt file or the Intel HEX file.

    See for a ready made solution (I've never used it though).

    Hope that wasn't too confusing.


    [Edited to add: the AL/AH is the 16-bit block address to start the block data RX, and LL/LH the length of the block. So to write a 64-byte block of data to the beginning of flash, AL = 0x00, AH = 0x80, LL = 0x40, LH = 0x00. ]

  • Robert Cowart said:
     I need the protocol for talking to the bootloader and getting it to update the application.

    This protocol is documented in SLAU319. Further, if you look at the zip file associated with the SLAU319 app note, you'll find some code for communicating with the BSL. If you are using one of the Flash based BSLs (5xx/6xx parts) you'll want to use the BSL Scripter (in the BSL Scripter folder), and if you are using one of the older or ROM BSL based parts (1xx/2xx/4xx) you'll want to use the BSLDEMO.exe that's in the Deprecated folder. These both provide demo scripts with executables you can run, as well as their source code so that you can see how they work. Note that you'll still need the right hardware to be able to use these software tools to do a software update using BSL via your PC- this is documented in SLAU319 section 4.1. The source code should help if you need to update the MSP430's code from some other processor.

    Hope this helps!



  • Thanks Tony,

      I'm using a cc430F6135.  It's a 5xx part according to slau319a.  I notice Kate below makes a distinction between Flash based and ROM based - Does it not work the same, or why is salu319a not making a distinction?  I'm porting the bslsh code to my application, I hope it will work.



  • Robert Cowart said:
     I notice Kate below makes a distinction between Flash based and ROM based - Does it not work the same, or why is salu319a not making a distinction?

    SLAU319 does highlight this distinction - see section 2 "ROM-Based Bootstrap Loader Protocol" on p. 11 and section 3 "Flash-Based Bootstrap Loader Protocol" on p. 23.

    The CC430F6135 has a Flash based BSL, so you should be able to use the BSL scripter downloaded here to communicate with it if you have the correct hardware as shown in Figure 4-1 of SLAU319



  • Hi Katie,

    My mistake. I see now the salu319a has a whole section on ROM based and a different one on flash based.  Arrgh.

    But I think the bslsh program works with ROM based not flash.   So the BSL Scripter is what I need.  Unfortunately I cannot test it, my hardware has no UART exposed so I can hook a PC up to it, it only goes to our Davinci.  So I have to port the source to that.

    Thank you for pointing me to that source, I think I can make it work.  I would be lost without that.


  • Do you know if erasing is necessary before writing?  Probably, right, because it's flash?

  • Definitely, flash segments have to be erased back to 0xFFFF before being written or you'll end up with gibberish :-)

  • Thanks!  I thought that but couldn't remember.  You guys are really fast at answering.

    Do you know how the BSL_Scripter code works?  I see where it transmits everything by copying the data into the buffer, but don't see where it hooks the buffer up to the port or terminal?
      answer = BSL_TX_Packet(TXBuffer);

    And RX is the same way...

    Anyway I'm trying MASS_ERASE first, let you know how that goes...

  • Wait, that'll erase my bootloader right?  Maybe I won't do that...  

  • MASS_ERASE won't erase your BSL area, it is safe to use. You may want to look at the example scripts in the folder BSL_Scripter/Demo Scripts - see the script.txt files for the different parts. You might also want to look at the scripter documentation in the BSL Scripter folder called "BSL_Scripter_Usage_Guide.pdf" if you haven't already.

  • That's confusing, the slua319a says

    All code Flash in the MSP430 is erased.This function does not erase Info Memory." .  then in  in the Flash Memory Controller section (Figure 5.2) BSL Memory is different from Info Memory.  so I thought it's erased.

    OK!  I'll try it.

    I see you're pointing out that if the script.txt uses it then I can use it.  Good point.

  • I don't know if you would know, but I'm getting some NACK codes when I try to mass erase that aren't in 319a.  Like 0x40 and 0xBE?  I tried searching, I can't find a good source for NACKs outside of the 0x51-0x56.

  • Mass Erase should be the same for everyone, right?  Is this right?

    Mass Erase:                             writing 0x80 0x1 0x0 0x15 0x64 0xa3
    answer: be

  • Hi Robert,

    For flash BSL, if the mass erase operation was successful the BSL should return ACK (0x00) followed by the BSL core message response, eg.

    Host: 0x80 0x01 0x00 0x15 0x64 0xa3

    BSL: 0x00 0x80 0x02 0x00 0x3b 0x00 0x60 0xc4

    The format is [ACK] [HEADER] [NL] [NH] [CMD] [DATA] [CL] [CH]

    See p30 of SLAU319a which has more examples in UART.


  • Here's basically what my code is doing ported to linux from Windows BSL Scripter.  output is same as above, only now it gets:

    Mass Erase:                             writing 0x80 0x1 0x0 0x15 0x64 0xa3 answer: 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78

    --code snippet--

    byte Buffer[300];
    int fh;
    unsigned int Size;

    int writeByte(byte data) {
      printf("0x%x ",data);

    unsigned char UART_5xx_TXPacket()
      unsigned int i;
      unsigned char answer;
      Flash_crcInit( 0xFFFF );
      printf("writing ");
      writeByte((unsigned char)(Size&0xFF));
      writeByte((unsigned char)(Size>>8&0xFF));
      for( i = 0; i < Size; i++ )
        Flash_crcInput( Buffer[i] );
      writeByte(Flash_getLowByte() );
      writeByte(Flash_getHighByte() );
    //0x00 0x80 0x02 0x00 0x3b 0x00 0x60 0xc4
      printf("answer: ");
      for (i = 0;i < 10;i++)  {
        read(fh, &answer, 1);
        printf("0x%x ",answer);

      if( answer != FLASH_ACK )
      return answer;

    *Function:    Flash_massErase
    *Description: sends the mass erase command to the device
    *             none

    *             char                  An FLASH_ACK if the dataBuffer is sent correctly
    //to do: wait for reply for FLASH_ACK?
    unsigned char Flash_massErase() {

      Buffer[0] = MASS_ERASE;
      Size = 1;
      UART_5xx_TXPacket( )  ;
    //  return getBSL_Response( BSL_TX_Packet(TXBuffer) );

    main(int argc, char *argv[])
      getBootloaderReady();  // I'm pretty sure this works because when it didn't work, I would pull reset high and it would reset.  Now it doesn't so I assume it's bootloader mode.

    //now in bsl mode, talk to bsl and erase it and program it.
    // erase it all first
    fh = open("/dev/ttyO5", O_RDWR | O_NOCTTY | O_NONBLOCK);

          // set up the port with 9600,8,EVENPARITY,ONESTOPBIT
          struct termios my_tios;

          tcgetattr   (fh, &my_tios);
          cfmakeraw   (&my_tios);

          cfsetispeed (&my_tios, B9600); // 9600 baud
          cfsetospeed (&my_tios, B9600);

          my_tios.c_cflag &= ~CSIZE;
          my_tios.c_cflag |= CS8;  // 8bit

          my_tios.c_cflag &= ~(PARENB|PARODD);
          my_tios.c_cflag |= PARENB; // even parity

          my_tios.c_cflag &=~CSTOPB;  // 1 stopbit
          my_tios.c_cflag &=~CRTSCTS; // no RTS-CTS

          tcsetattr   (fh, TCSANOW, &my_tios);

              printf("Mass Erase:\t\t\t\t");
          reply = Flash_massErase();
              if( reply == BSL_ACK )


  • So I put a scope on what I'm sending and getting back, and I'm actually getting back a 0x51, INCORRECT HEADER.  So I may not have my UART RX set up right, but I can accept that now probably my Command is going over there.  See anything wrong with the mass erase command?  I've gotten it from the datasheet as I understand it.

    0x80 0x1 0x0 0x15 0x64 0xa3

  • Hey Tony and Katie,

    I finally figured out my baud rate is wrong.  It's supposed to be 9600, my linux app sets it to 9600, but the waveform on the scope is at about 4000 which isn't helpful I can't get to 9600 from there.  So I have to configure the UART by editting it in the kernel or figure out how to get setserial to change the divisor for me.  Doh!  I may be going over to the 8148 forum now to ask about that. 

    Thanks for your help, it moved me along, I'll port here results.  I don't seem to be able to approve answers, I guess because I didn't create the thread?


  • So the Davinci dev board (and our board) use a 20Mhz crystal.  But the BSP Linux assumes a 48Mhz value for UART3, UART4 and UART5. So we'll be making a change to the Linux drivers at some level and commiting that back to TI's Davinci Omap2 branch.

    Thanks for your help, I think if the baud rate was right that would have worked!

  • hello, is there any other link for the files associated with the slau319 because the links are not working anymore.



  • Hi,

    The links in my post here should always point to the latest version of the document and zip file of slau319:

    I'll post them again:

    I do see that these documents were just updated again yesterday, so maybe if you tried accessing them sometime last night they may have been temporarily unavailable while the new version was being pushed to the website. I was able to open both of them just now though.

    For everyone's future reference - Please see also this post about making links that will always point to the latest version of a document on our website:



  • works great now, thx Katie