Forums

I assume you are using F5529, not G2403. Are you?

A few possible causes:

a. The contains of 0x4400-0xF7FF are not exactly the same as the TI-txt file. Some bits are not the same and you did not notice that.

b. The Flash is not erased completely or written completely. The can be read, but cannot execute reliably.

c. The code is not correct to begin with and dose not work as you expected.

d. The code assumes that the registers just come out of reset and thus have the BOR values. But your BSL has changed them already.

There was a small oversighted mistake,

My window side program was not made compatible with the larger TI-txt files which have intermittent gaps which need to be skipped or filled with 0xFF.

Now its working fine.

Hi,

I realize there may be a reason for you to want to implement a custom BSL, but I wanted to point out in case you were not aware that the MSP430G2403 is actually one of the value line parts that does already include a BSL in ROM (all G2xx3 parts have this, G2xx1 and G2xx2 do not). There are still reasons you might want to have a custom BSL though, if you wanted to use a different communications interface for example.

Regards,

Katie

Hi every one,

I am new to BSL programming. I have couple of quarries to get started.

1) Do we need to flash MSP430 Device with BSL 1st  ?

2) Is BSL different for device variants of MSP430 ?

Please help.

Regard s

Bhaumik Shah

Hi Bhaumik,

You can find the answers to these questions in the MSP430 Programming Via the BSL User's Guide (SLAU319). and on this wiki page: http://processors.wiki.ti.com/index.php/BSL_(MSP430)

Regards,

Katie

Hi Katie Enderle,

Katie Enderle

There are still reasons you might want to have a custom BSL though, if you wanted to use a different communications interface for example

The only reason to implement the custom BSL is that , the custom BSL has the full control over the main application about it's location in flash, it's execution, etc.

I am using my own simple communication protocol built over UART for flashing the main application.

Please let me know if anything is mistaken in this.

In addition to flashing main application via BSL, only through BSL the application shall be launched always (as only the BSL knows the main application location).

My intention is to blow the fuse once my BSL is loaded into the controller and there by allowing programming the controller only through my BSL.

Please let me know if there anything flaw in this.

I have three questions:

1. G2303 has only 4KB of Flash. How big is your BSL code?

2. How is your BSL protected from being altered (unintentionally) by your main program?

3. How is your BSL entered? If for some reason, your main program crashed, can one still start your BSL? (TI BSL has a hardware sequence to start BSL. Can it start your BSL?)

I am trying to implement BSL for G2xx1 and G2xx2. I am stuck with no good answers for the above 3 questions.

Hi old_cow_yellow,

old_cow_yellow

1. G2303 has only 4KB of Flash. How big is your BSL code?

My BSL is ~1100 Bytes so keeping 3 blocks of main flash memory, i.e 1536 Bytes for the BSL, remaining 2560 Bytes can be used for the main application.

(Here My main application is expected to be smaller one) Also the main intention behind this BSL is to provide controlled access to execute the main application.

Since I am blowing the fuse once I flash the BSL, I am providing the programming facility over UART through BSL so that the third party can program it's main application.

Depending on the main applicatoin size, I can opt for G2403 which has 8kB of main memory.

old_cow_yellow

2. How is your BSL protected from being altered (unintentionally) by your main program?

Currently a severe care is taken in the main application design to not to disturb the BSL.(I have not yet found the way to protect that particular part of the flash where BSL resides) Please let me know if you find any mechanism for the same.

old_cow_yellow

3. How is your BSL entered? If for some reason, your main program crashed, can one still start your BSL? (TI BSL has a hardware sequence to start BSL. Can it start your BSL?)

The reset vector contains the BSL's address, so unconditionally The BSL is invoked on reset. As I mentioned in my earlier threads, my BSL is just another application(App1) which on request will handover the control to the main application(App2).

Please let me know if anything is wrong in my explaination.

Chethu,

Using a scheme very similar to yours, I developed sort of a "customized BSL" for the MSP-EXP430FR5739 experimental board.

Like yours, the real Reset Vector (at 0xFFFE) always points to the beginning of my BLS. I implemented a “virtual Reset Vector” inside my BSL. After any kind of reset, my BSL will take charge. It looks at the cause of the reset and decides whether to execute Application according to the “virtual Reset Vector”.
 
FR57xx has Memory Protection Unit. I use that to protect my BSL as well as all the Interrupt Vectors. (total 512 Bytes from 0xFE00 to 0xFFFF.)  When the TI-txt tells my BSL to load the Reset Vector, my BSL will actually put that in the “virtual Reset Vector”. Also, if the Application program crashes and cause a reset, my BSL will trap unexpected resets too.

This works fine for FR5739, but I could not easily port it to G2xx. (Especially for the low-end chips.) I now have some idea, but un-tried yet. I think I can squeeze an abridged BSL into Info-Flash-B, -C, and –D. This is at the cost of a special PC program. Unlike the one for FR57xx, which only needs a Terminal Emulator at the PC side to send TI-txt file, this one needs the PC to send binary code with a special handshaking “protocol”.

Both the MSP-EXP430FR5739 board and the LaunchPad board has (a) built-in USB to Virtual COM Port, (b) Reset button, and (c) firmware readable button. I use (b) and (c) together to start BSL in loader mode. I use (a) to do the actual loading.

Regards,

OCY

Hi chethu,

Could I suggest a simpler "gate-keeper" bootloader where it normally loads the main program but can load the ROM BSL under certain controlled conditions (i.e. not just the normal BSL sequences on RST/TEST)?

Or you can just use the ROM BSL as-is.

The ROM BSL already has the capacity to be accessed through UART and be password protected, where if you enter the wrong password it automatically enters mass-erase mode thus ensuring the security of your code.

Tony

Edited: FYI, you can still access the ROM BSL after you've blown the JTAG fuse.

Hi old_cow_yellow,

old_cow_yellow

FR57xx has Memory Protection Unit

The FR57xx has the segment wise protection facility which is sufficient to protect the BSL. But no such features available in G2xx which is the reason for problem with BSL protection.

In addition, I have a doubt, I think I had pointed it in one of my previous posts,

FR5739 has a BSL memory in ROM which is specified in the memory organization section of the data sheet  also the functional block diagram shows the boot ROM. But why its not the same in case of G2304, the ROM BSL is not shown anywhere.

is it possible to program the G2xx after blowing the JTAG fuse, via the ROM BSL through UART like it can be done for FRxx and F55xx,

old_cow_yellow

squeeze an abridged BSL into Info-Flash-B, -C, and –D. This is at the cost of a special PC program

This was my original idea, but the main constraint was very less information memory in G2xx.

Hi Katie Enderle,

Sorry I missed out a point in my previous post,

Katie Enderle

but I wanted to point out in case you were not aware that the MSP430G2403 is actually one of the value line parts that does already include a BSL in ROM (all G2xx3 parts have this, G2xx1 and G2xx2 do not).

Nowhere in the data sheet of G2xx (SLAS734D–APRIL 2011–REVISED NOVEMBER 2011) its mentioned about the BSL ROM.

Please let  me know if I have to refer any other documents which says about the G2xx3  parts having the BSL ROM.

Chethu,

G2xx1 and G2xx2 chips do not have ROM BSL.

G2xx3 and FR57xx chips do have ROM BSL. But to use it, you need extra hardware so that the PC can initiate BSL Entry Sequence and can use parity bit.  The LaunchPad and FR5739 Exp Board hardware do not support these features.

The BSL code on the MSP430 side can be squeezed to ~192 Bytes and put in the Info-Flash.

OCY

Hi old_cow_yellow,

old_cow_yellow

G2xx3 and FR57xx chips do have ROM BSL.

My main intention in providing the programming feature through custom BSL is to secure some very important and sensitive data which is stored as part of the BSL  or in some secured location (My understanding was if I blow the JTAG fuse the flash content will be secure and to support my point the datasheet  (SLAS734D–APRIL 2011–REVISED NOVEMBER 2011) does not say anything about the ROM BSL of the G2xx3 using which the flash can be read/written).

But as you are saying the G2xx has the ROM BSL, can someone read the flash content through this ROM BSL?

If its possible to read the flash content through ROM BSL, how to protect this sensitive data from reading by someone?

Hi old_cow_yellow & everyone,

chethu gowda

My understanding was if I blow the JTAG fuse the flash content will be secure and to support my point the datasheet  (SLAS734D–APRIL 2011–REVISED NOVEMBER 2011) does not say anything about the ROM BSL

I sincerely apologize for the above statement which is completely wrong. Actually in the G2xx3's datasheet (SLAS734D) there is a clear mentioning about the BSL.

chethu gowda

If its possible to read the flash content through ROM BSL, how to protect this sensitive data from reading by someone?

The flash read/write operation through ROM BSL can be completely disabled by disabling the BSL using the BSLSKEY. Writing the word 0xAA55 at this location will completely disable the BSL. So I still retain the security for my data stored in the flash :)

I hope there is no other ways through which the flash data can be read/overwritten after blowing the JTAG fuse & disabling the BSL, if you think its still possible pls let me know.