Boot Loader code example in C

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

From http://www.ti.com/lit/ug/slau319a/slau319a.pdf 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.

Tony

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. http://www.datasheet4u.net/datasheet/S/L/A/SLAA089D_TexasInstruments.pdf.html 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: http://www.kernel.org/doc/Documentation/gpio.txt

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.)

Tony

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 http://www.ti.com/lit/ug/slau319a/slau319a.pdf . 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 http://llg.cubic.org/dmx43/bslsh.html for a ready made solution (I've never used it though).

Hope that wasn't too confusing.

Tony

[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. ]

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.

Thanks,

Robert

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.

Robert

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

"MassErase
All code Flash in the MSP430 is erased.This function does not erase Info Memory." .  then in http://www.ti.com/lit/ug/slau259b/slau259b.pdf  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?

Opened
Mass Erase:                             writing 0x80 0x1 0x0 0x15 0x64 0xa3
answer: be
FAIL(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.

Tony

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

Opened
Mass Erase:                             writing 0x80 0x1 0x0 0x15 0x64 0xa3 answer: 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78 0x78
FAIL(78)

--code snippet--

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

int writeByte(byte data) {
  printf("0x%x ",data);
  write(fh,&data,1);
}

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

  printf("\r\n");
  if( answer != FLASH_ACK )
  {
    //clearBuffers();
  }
  return answer;
}

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

*             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);

sleep(1);
      // 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);

sleep(1);
          printf("Mass Erase:\t\t\t\t");
      reply = Flash_massErase();
          if( reply == BSL_ACK )
          {
        printf("DONE\n");
          }
          else
          {
        printf("FAIL(%2.2x)\n",reply);
          }

}

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?

Robert

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.

Regards,

Claoo 

Hi,

The links in my post here should always point to the latest version of the document and zip file of slau319: http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/95827/622705.aspx#622705

I'll post them again: www.ti.com/lit/pdf/slau319 www.ti.com/lit/zip/slau319

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: http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/251542/1129836.aspx#1129836

Regards,

Katie

works great now, thx Katie

regards,

Claoo