MSP430F5 (A or Not) BSL activation

1) The PC is not "too fast". It is Windows that is too slow. I can even use a 1980 vintage PC under IBM-DOS to to it. Windows require faster PC but is much slower with Microsoft "Advanced Technology".

2) Non-A Rev L is shipped with a working BSL. The BSL Script in PC from TI works too.

3) I use IAR Kickstart IDE. I can see the BSL Flash. But others told me that they cannot. I do the following. (a) Set up Kickstart to "Allow erase/write access to BSL flash memory". (b) Go into "Debug without Downloading". (c) Set SYSBSLC to 0x0003. (d) And view memory from 0x1000 to 0x17FF.

4) I can do it with IAR Kickstart. I cannot use CCS.

Hi and thanks for the answer,

1) "Too fast" is the required low pulse duration on TST for BSL to start with an F5438A (See Knoiwn bugs of 5438A in SLAU319a.pdf documentation, driving RTS signal form a Windows PC can't be so fast ...

2) I could read the binary data of the protected area wiht such a code, the break on the last line, en have a look to  read_BSL_mem then it seems no empty.

define BSL_START 0x1600

#define BSL_END 0x1800

char read_BSL_mem[BSL_END-BSL_START];

int 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;

}

}

3) I'm using CCE and it's definitely impossible to read protected area 0x1000-0x17FF for me with the debugger ?

NEW POINT:

I also tried to start BSL with a Jump to 0x1000 and i had a strange behaviour.

SYSBSLC &= ~(SYSBSLPE+SYSBSLOFF);

_DINT();

((void (*)())0x1000)();

Here are some screenshot of a little digital analyser on my lines connected to RESET/TEST/TA0.0/TA0.1. With the simple BSL_Script

MODE 543x_family COM9
VERBOSE
CHANGE_BAUD_RATE 9600
TX_BSL_VERSION

I've a strange repeted "Break"  (maybe something else) sended on the Tx line (TA0.0) of the MSP430F5438, and my 2 BSLScripter  frames on Rx seem ok ?

Any idea ???

Notice that i presume all the UART configurations should be 9600/8/No parity/1stop bit

Hi all,

I've got now a working solution !

So i'd like to expose it and maybe try to find answers for stranges behaviour, to my mind. But i'm surely missing something about MSP430F5438A working modes...

I get to properly use the BootLoader using the following configuration:
- Dongle FlyingCamp FCD-PRG01 with a configuration inverted DTR and RTS on the driver's for the FTDI FT2332 device contained in the dongle.  I used FT_PROG progra from FTDI.
- The proposed BSL-Scripter from TI (slau265j)
- With a BSL "slaa450 \ Custom BSL Zip File \ Source Released BSL \ MSP430F543xA 00.05.04.03" recompiled with IARKick
with some modifications made to source code:
  -> To Adapt to our I / O available on the current map (P8.0 and P8.1 used instead of P1.1 and P1.2)
  -> Correction of the parameter definition InputCapture (CCIS1) for the 4358A in the source of IAR ....
... whew ...

But in any case I have something interesting to find out.

In nominal terms (slau319a) I can not switch BootLoader.

See the first timeline below. Notice that the "rapid switching" of TST7 shows a small program toggling an I / O, so, as long as it is there, the MCU runs on the prgm and not the BSL. You can see that it is the case even if the the boot sequence is correctly sended (See RESET and TEST).
This is probably not functioning because of the known Bug of 15uS (see slau31a). But the most interesting is the second timeline.

First, the second timeline shows a sequence that is correctly getting the MSP430F5438A in BSL mode !
You will notice that the MCU rocking well into BSL and exchanges are carried out properly, using with bsl-scripter, on Tx and Rx (PASSWORD VERSION).

BUT the strangest is also on the second timeline :
You can see the presence of program operations while USER RESET is back down to LOW. Why  ?????

it's not really a problem for me but i don't really understand all these "not nominal" behaviours.

I'm surely missing something ... any opinion ?

Is the 15uS pulse on the TEST pin to enable the BSL going to be fixed in a later rev since it is listed as a "bug" and is a real pain in the ___?

I agree, it would be nice to know if this bug (15 us constraint) will be fixed ?

I would also like an answer to this strange behavior ... that saves us for F543xA ;O) ... I mean a proper entry into BSL if the TEST signal is inverted (two rising edges instead of  two falling edges) ?

Hello peg!

You're right, bsl entry of MSP430F5418A or MSP430F5435A is possible using inverted TEST signal sequence! It's like bsl entry of the MSP430F1132 microcontroller. 

I've tried this method on my MSP430F5418A and MSP430F5435A - bsl works correctly! I think it is very good workaround of 15 us bug!

I was very lucky when i discovered this "workaround" but if it can be useful for anyone else i'll be happy ;O)

Regards

MSP430F5418 Rev.E v/s Rev. L

I am not able to program  MSP430F5418 Rev E using MSP-FET430UIF (using IAR Workbench)

but All these are fine with MSP430F5418 Rev L

So, What to do?

Kindly help me for these.