Flashing two images on the same controller

Hi chethu,

i think the most important things to be noticed on implementing the custom BSL on 2xx devices are:

- make sure that your BSL code and application code reside in separate segments on the flash memory. Because the smallest memory part which can be erased is a segment (512 bytes for main memory).

- Another common problem is the interrupt vector table which resides at the end the 64 KByte memory address. The reset vector has to always point to the starting point of your BSL code, but the other interrupts are used by your application usually. In this case, you should implement a double jump mechanism.

Please see the following wiki page for more information:

http://processors.wiki.ti.com/index.php/BSL_%28MSP430%29

especially the part : Overall Guidelines for ROM-based BSL (1xx,2xx and 4xx Devices), and General Custom BSL FAQ

lhend said:

... make sure that your BSL code and application code reside in separate segments on the flash memory. Because the smallest memory part which can be erased is a segment (512 bytes for main memory)...

The Info-flash segments B, C, and D can be used to store the BSL. They are 64 bytes each thus the total is 192 bytes and sufficient for BSL.

lhend said:

... Another common problem is the interrupt vector table which resides at the end the 64 KByte memory address. The reset vector has to always point to the starting point of your BSL code, but the other interrupts are used by your application usually. In this case, you should implement a double jump mechanism...

The real common problem is most engineers do not know how to do things efficiently and live within their means. A simple BSL does not need to use any interrupt. Thus In this case, you should NOT implement a double jump mechanism.

Hi Lichen,

Lichen Wang88934 said:

The Info-flash segments B, C, and D can be used to store the BSL. They are 64 bytes each thus the total is 192 bytes and sufficient for BSL.

Well it is possible, bu i think you need to write your BSL in assembly code this way. But of course this is possible, and just FYI we will publish an application note on implementing BSL which reside in the INFO memory.

Lichen Wang88934 said:

The real common problem is most engineers do not know how to do things efficiently and live within their means. A simple BSL does not need to use any interrupt. Thus In this case, you should NOT implement a double jump mechanism.

I am talking about the application code which uses the interrupt vector table here not the BSL code. For the BSL code of course i would also recommend to not use any interrupt (that's why the default MSP430 BSL is using Timer_A for UART interface).

The double jump mechanism is useful because the application code could differ from one version to another and the ISR code could also take different addresses in the flash memory. IMO, the best way is to implement the BSL code at the last segments of the flash memory which includes the interrupt vector table. The reset vector will always point to the starting point of BSL code, while the other vector points to a location in the INFO memory which stores the jumping instruction to the application ISR code. Since the application code should reside at the beginning of flash memory, the last segments of main memory will be left untouched. Everytime the application code needs to be updated, you just need to update (erase and write) the beginining of flash memory where the application code shall reside and also the jumping table in the INFO memory.

-Leo-

Lichen Wang88934 said:

A simple BSL does not need to use any interrupt. Thus In this case, you should NOT implement a double jump mechanism.

This is non-trivial postprocessing of the generated binary. Not impossible, but also not really fitting the idea of a 'simple BSL' in terms of 'easy to implement'.

lhend said:

For the BSL code of course i would also recommend to not use any interrupt (that's why the default MSP430 BSL is using Timer_A for UART interface).

Hi Lichen,

Lichen said:

A simple BSL does not need to use any interrupt. Thus In this case, you should N...

Here, rather the BSL is just another application using UART communication to talk to another controller, On succeessfull validation of which the second application will start working. Here there would be a simple jump from the first application (so called BSL) to the main application.

and unfortunately both applications uses the UART to communicate with the other controller, and I need to use a single UART tx/rx interrupt handler for both the applications to reduce the footprints of applications.

Hi chethu,

chethu gowda said:

and unfortunately both applications uses the UART to communicate with the other controller, and I need to use a single UART tx/rx interrupt handler for both the applications to reduce the footprints of applications.

I think it is also possible to implement the UART communcation in your BSL code without using any interrupt. You can basically just poll the status bits, e.g. UCBUSY in UCAxSTAT register or UCAxTXIFG and UCAxRXIFG in IFG2 register. This would make the implement easier and won't give you so much headache :)

Hi,

The plan what I have in my mind is.. lets have 2 applications (lets not call the first app as BSL for now)..

I will have the interrupt handlers of UART as part of the app1.. and app1's start address is programmed into the reset vector. on bootup the app1 will communicate with another controller and on successfull evaulation the controll will be given to app2(The main application)..

Here I want to make use of  the app1's UART ISRs for my main communication with another controller.. and my plan for this is as follows (jsut a plan.. and pls correct me if my thought process is wrong or not feasible),

I will unlock the flash's info memory section for read/write operations in app1, I will make use of flash's info section to store the received data in UART ISR.. and so on..

when the app2 is running, I hope I can make use of same app1's UART ISR and since I know the data is being dumped into the flash's info memory section, I can handle it just the way it was done in app1.

Hi lhend,

lhend said:

You can basically just poll the status bits, e.g. UCBUSY in UCAxSTAT register or UCAxTXIFG and UCAxRXIFG in IFG2

Thanx for this valuable information.. but will this by any means increase the footprint of image on flash compared to what I have though of, like sharing the UART ISRs?

Hi chethu,

chethu gowda said:

Thanx for this valuable information.. but will this by any means increase the footprint of image on flash compared to what I have though of, like sharing the UART ISRs?

I think this is not necessary increasing the footprint, usually polling a flag if you write in C usually will look like this:

while(UCA0STAT & UCBUSY);

This will be translated only into two assembly instructions:

loop: bit.b #UCBUSY, &UCA0STAT

          jnz loop

If you try hard to make your code as efficient and compact as possible, it is possible to implement the custom BSL on the G2303. Remember that the F5xx BSL is written in C and only occupy 2 KB flash space.

Hi lhend,

lhend said:

Please see the following wiki page for more information:

http://processors.wiki.ti.com/index.php/BSL_%28MSP430%29

especially the part : Overall Guidelines for ROM-based BSL (1xx,2xx and 4xx Devices), and General Custom BSL FAQ 

 

I went through this link but I could not get the complete picture about the implementation of the custom BSL on ROM based BSL controllers like 2XX. Also the datasheet of msp430G2303(SLAS734D) does not say much about BSL it points to 'Bootstrap loader user's guide(SLAU319)' which only talks about the flash programming through BSL.

I have following doubts related to this,

1.what is the physical location of the BSL in flash for msp430G2303 if its sitting inside the flash?(

in datasheet of msp430G2303 (SLAS734D) there is no mention about the ROM, The block diagram also shows only flash, so I assume that the default BSL from TI is sitting inside the flash.

)

1.what exists in flash of msp430G2303 at locations between 0x0300 - 0x0FFF and between 0x1100 - 0xEFFF?

2. When we are talking about the custom BSL for ROM based BSL controllers(or 1/2/4xx series), are we really overwriting the existing default BSL or just programming custom BSL  and main application to main memory with default BSL as it is.

3.Can I apply the mechanism mentioned in 'creating a custom flash-based bootstrap loader(SLAA450A)' according to which programming the BSL's signatue and BSL start vector at locations between 0x17F0 - 0x17FF will handover the controll to custom BSL?

chethu gowda said:

Hi Lichen,

A simple BSL does not need to use any interrupt. Thus In this case, you should N...

Here, rather the BSL is just another application using UART communication to talk to another controller, On succeessfull validation of which the second application will start working. Here there would be a simple jump from the first application (so called BSL) to the main application.

and unfortunately both applications uses the UART to communicate with the other controller, and I need to use a single UART tx/rx interrupt handler for both the applications to reduce the footprints of applications.

[/quote]

(a) We have two independent applications sharing the Flash memory. The first one is normally dormant. During that, it only occupying a small amount of the Flash.  The second one is normally active and perform ordinary tasks as the user desires.

(b) We must have a way to stop running the second application and activate the first application.

(c) When activated, the first application must be able to erase all the Flash that itself is not using, load that Flash so that it becomes a new "second application".

(d) After that, we must have a way to stop running the first application and activate the new second application.

I am doing the above with a LaunchPad and MSP430G2xx.

(a) The "first application" occupies Info-B, C, and D (192 bytes).

(b) The way to activate the "first application" is to press the RESET button while holding the SW2 button depressed.

(c) A custom program is need on run a PC or something, using the USB interface on the LaunghPad to erase and load new "second applications".

(d) Power-up, or pressing the RESET button without holding SW2 will start the second application.

 

.