Entering BSL mode with MSP430F5438

Hi,

   It's not something I've done specifically using a comm program.  For sending and reciving specific commands, as well as seeing verbose output of device communication, I'd simply use the BSL_Scripter application that comes in the BSL Memory Programming User's Guide (SLAU319)

   The zip file also includes source code, showing you how to toggle the TST/RESET pins.

Entering the BSL requires a special sequence on the reset/test pins of the MSP. While this sequence can be programmed through a normal RS232 connection (by abusing the otherwise unused RTS/DSR (?) signals), no normal terminal program can actually do this.
I tis, however, no problem doign this through the normal COM port driver mechanisms. Jus tthat typical terminal programs just have no clue that this special kind of handlign could be possible,

Some terminal programs (I remember one way back in DOS times) did have a scripting language which allowed toggling these pins under user script control.

It's also possible to write a scrip that toggle sth epins and then launces e.g. HyperTerm in 'no handshake' mode, so the BSL entry sequence has been triggered before HyperTerm takes over the port.

Since the BSL cannot be accessed by readable commands (it's diven by binary control sequences), however, the use of a terminal program isn't recommended at all. Either write your own applicaiton using e.g. VC++, or use the BSL scripter mentioned in Brandons Post.

 

Could someone shed some light on the following errors when using the BSL_scripter program with the experiementer board for the F5438A? 

inside the following script.txt file:

MODE 5xx COM1
MASS_ERASE
RX_PASSWORD
RX_DATA_BLOCK Big_File.txt
CRC 5C00 1000 982B

 

C:>BSL_Project\BSL Scripter\bsl_scripter script.txt

 ------------------------------------------

BSL Scripting application 1.06

The local time is: 14:19 on 25.10.2010

------------------------------------------

Initializing, Mode: 5xx COM: COM1       DONE

Mass Erase:                                        FAIL(ee)

RX Password:                                      FAIL(ee)

Writing Big_File.txt to device: FAIL writing data block starting at 5c00

CRC from 5c00 of 4096 bytes to 982b   FAIL

 

Thanks, Jim

What hardware device did you connect to COM1 of PC? And how was it connected to your F5438A?

I think if you do not connect anything to COM1, the BSL-scripter would give you that same error message. Am I incorrect?

You are correct.  0xEE is the code for timeout.

 

Any one of these could be the cause of this:

• Incorrect COM, or incorrect/no hardware connection between the PC and 430
• BSL not actually in the device
• Invoke sequence not working.

The last point is somewhat important... as the 5438A has a bug which the non-A version does not: The low time on TEST must be less that 15 uS.  This is not achievable using a PC, so if you want to do BSL communication with this device, I'd recommend using another micro, or make a small program in User Code which simply jumps to 0x1000 at startup, forcing a BSL entrance in any case.

I'm connected to the usb port on the F5438 experimenter board.

Also, I noticed several of the functions in the BSL_scripter project are nowhere to be found.  They're declared function pointers, but nowhere in the project.  Are they in some library somewhere?

Would it be possible to share the MS Express project 2010?

Thanks.

-Jim

>I'm connected to the usb port on the F5438 experimenter board.

This will not work.  The 5438(A) and other BSLs communicate via UART.  You will need hardware for Serial to UART conversion... or, since there is an invoke bug on the A version... use another connected microcontroller's to send characters via UART.

>Are they in some library somewhere?

I'll need more info here, perhaps this is an issue with USB?

>Would it be possible to share the MS Express project 2010?

One of my long term goals will be to bring up the BSL scripter to MS Visual Studio Express 2010.  This will be some time though.

Okay, I'm looking at the F5438 experimenter schematic.  I have a 5438A in the socket and need to use this chip.  I'm new to this micro and see it's not easy to get this into BSL mode.  When there is a bug for a pulse with of < 15uS, how does one get this into BSL Mode and download a binary via the com port.  Even if I use the TI JTAG FET430UIF probe, how can I toggle the TEST pin twice, with one pulse having to be <15us?  I realize this is a redundant question, but do you see the issue?

From what I can see, there is no way to easily have an end user upgrade their code without some kind of external hardware.  OR worse yet, have an engineer (me) play with the development stuff and come up to speed with the BSL.

So it looks like the only way to get this micro into BSL is to write a custom BSL loader.  Is this what your advising?  Do you know of any way of using the tools I've mentioned to get this experimenter into BSL mode?... that is, using the experimenter pcb and FET probe?

Thanks.

Hi,  I see what you are saying, and you are correct.  Using a basic PC to BSL connection as supplied by TI there is no way to hit the timing requirments.  Obviously building a custom invoke and communication system is also possible, but requires quite a bit of effort.

For an 'off the shelf' BSL solution, look at Elprotronic's FlashPro430, which supports the BSL (albeit via a custom JTAG header which would need to be routed to our BSL header)

All questions pertain to the F5438A... I am really stumped on what TI's BSL is doing.  I've read the documentation and am still confused. Please help.

I'm looking at the project you guys (TI) did called MSP430F543xA 00.05.04.03.

I think you're following the table in the Datasheet for BSL pin assignments.  First question 1.) the spec shows P1.1 and P1.2 as Data TX and Data RX respectively.  Is your code bit-banging the data?  2. )Is this code interfacing to some Host PC Program?  3.) All I currently have to play with is the Experimenter board.  If I understand your last post, there is no way to get this board into BSL Mode, correct? 4. )I noticed I cannot view the BSL addresses in IAR, is this correct? Nor the code at these addresses. 5.) Is the code in this MSP430F543xA 00.05.04.03 project the code that TI ships with the F5438A processor?  If not, where can I look to see what the code looks like?

Thanks for you time.

-Jim

I use the IAR KickStart and am able to look at the BSL Flash contents.

Set up the [Project] => [Options...] => [FET Debugger] => Tab:Download with the "Allow erase/write access to BSL flash memory" checked. Also, modify the SYSBSLC register if needed once you are inside the Debugger.

Hi, Sorry about the delay, some answers:

 

1) The BSL is using the Timer_A to communicate via UART

2) Correct, there is a host PC program provided in SLAU319

3) There is no standard BSL header on the board.  However, to enter BSL mode, all one needs is access to TEST, RESET, P1.1 and P1.2.  This is not easy on the experimenters board, as P1.1 is connected to an LED. 

3a) Getting the signals out is only half the battle however, you also need a way to communicate with the BSL.  This can be done using either a PC host program using Serial to UART conversion hardware, or another micro.  Using a PC is especially difficult for the 5438A due to the BSL invoke timing being too fast for most PC serial ports (as an alternative, I just put in user code which sets the PC to 0x1000 immediatly after startup, forcing a BSL invoke on RESET)

4) See previous post

5) Source code and images for all BSLs can be found  in SLAA450

Thanks Lance.

I'm trying to view the code in the BSL area at 0x1000 using IAR.  Here is a snippet of code to jump to the BSL and view the code that resides there.  One problem, all I see is 0x3FFF when I vector there.

void main(void)

{

    WDTCTL = WDTPW + WDTHOLD;               // Stop WDT

    SYSBSLC = 0x0003;                                      // clear protect bit

   ((void (*)())0x1000)();                                  // jump to BSL

    _nop();                                                         // For debugging

''

''

''

}

Can you shed some light on this?

-Jim

Hi,

  I think your code would simply remove the protection bit, then start the BSL (the second part being unnessecary).  What I've always done is simply remove the protection bits, then read the BSL code into RAM where I can easily read it with the IDE:

#include "msp430x552x.h"
#define BSL_START 0x1000
#define BSL_END   0x1800

char read_BSL_mem[BSL_END-BSL_START];

void main (void)
{
  int i;
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer
  SYSBSLC &= ~(SYSBSLPE+SYSBSLOFF);

  for( i = BSL_START; i <BSL_END; i++)
  {
    read_BSL_mem[i-BSL_START] = *(char*)i;
  }
  i--;                                      // set breakpoint here
 
}

Jim Patten said:

One problem, all I see is 0x3FFF when I vector there

The MSP flash controller differentiates between instruction fetch and data fetch. JTAG access is data fetch. The BSL area is protected against data fetch unless the data fetch is initiated by code running inside the BSL area. Also, I think that even an instruction fetch is ionly possible if the previous instruction was already in BSL area, except for a small area on the BSL beginning (unprotected).

The BSL protection is quite complicated and I don't exactly remember the conditions.

Hi Lance,

I'm using the F5438A flavor.  Are you saying that I cannot set a breakpoint in the BSL area (using IAR), set a function pointer to address 0x1000, and step through the code?  Also, how does one write a new BSL and download it to the BSL segments?  Do I have to manually modify the linker file?

Thanks,

-Jim

 

Hi Lance,

I am using a 5419 (Non-A).  Can I use the jmp 0x1000 method from my app to get to BSL Mode?

Hi,we have the same question that we can't enter the BSL mode when use msp430F5438A,at first we can do this with MSP430F5438, beacause this microchip was already end of life,we use MSP430F5438A to instead of it, but we find that we can't upgrade the code though BSL mode. Now we kow that"the 5438A has a bug which the non-A version does not: The low time on TEST must be less that 15 uS", and as Lane Westlund said we can't do this when use PC to upgrade.And we noticed that Lane Westlund suggest we can " make a small program in User Code which simply jumps to 0x1000 at startup, forcing a BSL entrance in any case " . Does it work like a bootlooder , when the MCU powerup the code jump into BSL mode and check whether need to do upgrade , if not it begin to run start main ? We ask for TI department in China , they say they do not have the competence to get the code , and suggest seek for some help form here , can anyone send the code to me , my e_mail is liersong1@163.com . Thank you very much.

Ersong Li

ersong li said:

Does it work like a bootlooder , when the MCU powerup the code jump into BSL mode and check whether need to do upgrade , if not it begin to run start main ?

The MSP hardware detects teh entry sequence (toggle of TEST pin during RST low) and sets a hardware flag if this sequence was applied after RST was going low last time.
The boot code that is executed right after power-up/hardware reset checks whether a BSL is available (on those MSPs that have a writable BSL area) and calls a 'do you want to execute' function inside the BSL whcih tests this hardware bit and either starts the bootloader or jumps to the RESET vector (the start of the user program, usually the C init code tha teventually runs main).
On MSPs with fixed BSL in ROM, the boot code directly checks the flag and either jumps to the BSL or to the reset vector.

If you want to ente rthe BSL manually, you have to do the check inside your main. When main is called, check whether an update is requested (by checking an I/O pin or whatever) and then eithe rjump to the BSL or continue executing main. This shoudl be done before changing any default values (liek cklock module ot port pin configuration) or the BSL might not work, as it expects the defaults.