MSP4305438 BSL

It's not clear what your problem/question is.

You'll need to manually handle the RST and TEST pins of an MSP to enter BSL mode, or your already installed firmware calls it directly.

If writing your own BSL application (PC-side), you can do so by manipulating the DSR/DTR and RTC/CTS lines manually, abusing them as I/O pins and connecting them (after proper level-shifting) to the RST and TEST pins.

Teh BSL code of the 54xx (and all other MSPs I know of) does NOT use the internal UART hardware, it uses the port1 I/O pins instead, as this is mostly hardware-independent and also allows smaller code and does not rely on any assumption about current clock settings.

If you want it differently, you'll need to write your own BSL for the MSP, which is only possible on some MSPs (namely the 54xxA series, but not the 54xx, and few others)

I read SLAU265i

How do I do the sequencing through the Serial port? When I double click on BSL_Scripter it just closes. Am i doing something wrong?

 

Thanks

Harsh

 

 

Thanks a lot !! 

 

It solved one question.

 

Another Question:- How do I erase the TI BSL from the memory location? Can I do this through JTAG? 

 

This is for 5438 A

 

Thanks

Harsh

Harsh Patel

Another Question:- How do I erase the TI BSL from the memory location? Can I do this through JTAG? 
This is for 5438 A

I'm not sure. Usually, programming the MSP through JTAG will upload a small program into MSP ram and let it do the acutal programming. The BSL area needs special handling, so I don't know whether it is supported. Maybe, may not be, I think it depends on the programming software used.
The 5438A is relatively new so there isn't much experience. Personally, I use the non-A as it is significantly cheaper (important if you build more than just a handful devices).

As a workaround, you can write a program that is put to normal code flash and when it starts it will update the BSL area from the included code.

I just built my own BSL (or rather flash update) code which works with double-buffered data transmitted during normal operation (e.g. using existing RF communication) and is as fool-proof as the BSL (even if transfer or flashing failed, the device will recover, either back to old firmware or successful update). So I didn't care for the BSL area.

Thanks Jens-Michael Gross !! A lot!

 

I have a few more questions. Hopefully you will be able to answer it!

 

1. If my code size is suppose 60 KB is it safe to assume that it will reside in the first sector of the flash bank?

2. I am planning to implement a Bootloader in the Main code memory. So  I am thinking to implement my bootloader in first sector of Flash and remaining three sectors to be Application code. Is it ok ?

3. My Bootloader would initialize I2c port. If I want to use that I2c port in my application how do I use it? Because my bootloader and application code would be two separate .out files?

 

Thanks

Harsh

Harsh Patel

1. If my code size is suppose 60 KB is it safe to assume that it will reside in the first sector of the flash bank?

Usually, the linker starts piling up the code from bottom (first flash bank). Normally, this is the runtime library code, the C++ reset function (which initializes variables) etc. Then your code.
If you don't use every byte, there will be a gap where the code ends, and then the interrupt vectors are written from 0xffff down
You can have some influence to the position of your code by assigning fixed addresses. Dependign on how you do it, the linker will eitehr sort the rest around these fixed places or complain if the heap it is building overlaps on of the fixed areas.
You can also alter the linker script file for the processor, by adding additional sections at fixed places. So if you tell the compiler that a funciton belongs to one of those additional sections, it will be placed there.
You can ask the linker to put out a map file where you can find what has been placed where.

Harsh Patel

2. I am planning to implement a Bootloader in the Main code memory. So  I am thinking to implement my bootloader in first sector of Flash and remaining three sectors to be Application code. Is it ok ?

you can as well write it to the last 4 sectors.
Or you integrate the receiving part into the application, write it down to an unused flash area and then at the next restart, the small boot code will detect that there is something to update and will do the update from flash to flash. So the bootcode is small and the receiving code can be as complex as you want. Encrypted, password-protected, wireless or in the background of normal operation. My own BSL works this way.

Harsh Patel

3. My Bootloader would initialize I2c port. If I want to use that I2c port in my application how do I use it? Because my bootloader and application code would be two separate .out files

No problem. If the BSL initializes the I2C (maybe as slave? Or as master, accessing a data storage slave), it just needs to put it back into reset state (set the SWRST bit) and all is back to start, so your application won't have any problem. It will not even notice.