Forums

If you are working on a 4xx, BSL is in the BSL-ROM of the chip. Application code can only reside in Flash or RAM. Both Flash and RAM are separated from the BSL-ROM. And ROM cannot be erased.

Yes I know, the BSL code is on the ROM, see wiki link above. I would like to do what's in the wiki, and I don't know how to separate 'myBSL code' (invoking the BSL from software) and the application code on the flash. Perhaps this is a bit more to the point. Please read the wiki, it's no point of having me reciting it.

I did not read the wiki before. I think the entire Section 3: Overall Guidelines for ROM-based BSL (1xx,2xx and 4xx Devices) does not make any sense under that heading.  I think they should be under the heading: Custom MSP430 BSL for 1xx/2xx/4xx Devices.

For 1xx, 2xx and 4xx, there is a ROM-based BSL in ROM. It is already protected and it is already separated from the application. If you want to implement a Custom BSL in Flash, then you have to think about how to protect it and how to separate form the application.

I just like to implement what's in the wiki, Section 3: Overall Guidelines for ROM-based BSL (1xx,2xx and 4xx Devices). Any suggestions how to do this? 

I am currently trying to do this as well. 

I am using a 2619 and have a very limited pin out.

From what I gather from the wiki, is that you make a custom bsl section in the linker command file, then when (lets say the UART) recieves the command "Firmware Update" it starts the users firmware update code: ie you make some protocol and erase the flash that you want and reprogram it from the .hex file information streaming in from the UART. 

At least that it what it seems like...

If I get anywhere with this today I will post up my code.

Derek 

Ok well after reading the program "appl.c"  it is a little more appearent how to impliment this. 

If you download the CUSTOM_BSL_APP.zip and CUSTOM_BSL.zip. files from the wiki page it goes through everything. 

I will attempt this again when I am actually at my desk for the day.

I have played with this quite a bit and cant seem to get a working version. 

I set up a system like in appl.c in which I separate the flash memory (f2419-two flash memory sections) and go to the address where the "bootloader" is located. 

In the bootloader I manually put in a string[] that contains the contents of a ti-hex file.

The problem with this is that when you erase the flash you loose the c_int00 information. I tried a few ways around this but I could not get it to cooporate. 

There is also a bug of some sort in the rts library, since I could not install manually a c_int00 section into the linker file without getting errors. 

Then I found some one on the e2e forum saying that you needed to make the "bootloader" into two seperate projects. http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/47205.aspx

I did this and found that when I would jump to my custom "bootloader" it would not execute the code. 

There seems to be quite a few threads on this, but there are no concrete examples anywhere to be found.

Anyone have any comments on this?

Derek,

The immediate problem you are facing is the limitation (or "feature") of the tool you are using. What are you using? And in c or assembly? The limitation (or "feature") can be worked around.

Once you managed to load both your Application and your BSL in Flash (at separated segments), how do you decide which one to run after Reset? And how to switch to the other one?

--OCY

I have been pondering this as well. My immediate thought is that I make  a custom reset vector for the BSL that is called by software. Then have get the run time enviroment up and running. That seems to be the tricky part. Oh and I am writing in C.

The only other issue with that I am finding so far is syntax. I can not seem to get it to work in the Linker file. (With the C2000 I can do this, but I get an error with the 430)

 

I wonder why people would want to follow the ‘Overall guidelines for ROM-based BSL (1xx, 2xx and 4xx Devices)’, from the TI wiki: http://processors.wiki.ti.com/index.php/BSL_(MSP430)

That guideline essentially says:

(1) Those devices have a ROM-based BSL But ignore that BSL and roll your own BSL.

(2) Your own BSL will only start if the CRC check of your Application is incorrect. Otherwise your Application will automatically start.

This seems to mean:

(a) Overall speaking, the ROM-bases BSL is worthless.

(b) The CRC check of our Application may corrupt and at that time your BSL can reload your Application.

(c) Other than that situation, if you want to run your BSL, you have to wait (or cause) a CRC check of your Application.

I will post up a more thorough post later, but I got two seperate projects running on one chip. Now I just have to implement the UART to the bootloader/monitor project to load the data into the sections that are being reflashed. 

I will post my code when I get the custom BSL finished.

old_cow_yellow

Overall speaking, the ROM-bases BSL is worthless.

Not that's not a conclusion but a prerequisite for needing an own BSL. Mostly because you want a different kind of interface than provided by the rom-based BSL. Even then, the rom-based BSL isn't worthless, it just doesn't suit your needs.

old_cow_yellow

Other than that situation, if you want to run your BSL, you have to wait (or cause) a CRC check of your Application.

Yes, that's the weak part. However, you can simply define an input pin as a 'force BSL' pin. If it is tied to GND by a jumper on startup, the BSL will always start. If you cannot come up with a simple solution such as this, you shouldn't try implementing your own BSL at all.
I agree that this could have been added to the guidelines.

The whole section should be rewritten, since as it stands there's no mention of actually using the ROM BSL anywhere. And the "guidelines " seem to be a hodgepodge of things for ROM and custom BSL.

Tony