Bootcode looking for 0xFFFF@0xFFFE

Johannes Barteit said:

if it is present only in the 55xx and 56xx MCUs or if this also would work with other MSP430s

I tis a nice trick you use, but it is only necessary if not doing a mass erase anyway before starting the programming process. If you do a mass erase, the address @fffe is already 0xffff before the flashing begins. And as long as your code fits into the lower 64k, the reset vector is the last value written.
If your code is larger, however, the reset vector will be updated before the upper flash is written and your trick works only for the first part of the programming. If power fails after the reset vector was written (during the write of the area above 0x10000), the device will still lock-up.

Hi Jens,
thanks for the answer.
Is it possible to split the TI-txt File and send the first 64 k, then set FFFEh to FFFFh  and send the next 64 k after that?

I don't have a TI-txt file to work with. How does a TI-txt file look for program code that is bigger than 64k?
So I have this txt File for programs bigger than 64k. They only have one Position information and the rest is data.
Now I have to find the FFFEh Part in this big sector and save it in a second TI txt. Than I can overwrite it with FFFFh.

And another question: Where can I find out if the FFFFh@FFFEh works on the device?
I would like to make a list of the MSPs we use here and note if they can use this feature or not.

Johannes Barteit said:

How does a TI-txt file look for program code that is bigger than 64k

@5c00
(code)
@ff80
(vector table data)
@0000
(0x10000 test data)
@fe00
(initialized data structure @0x1fe00)

I'm not sure what hapens if you want to put soimethign @ 0x20000 but don't have anything in 0x10000. Do you have to generate a dummy segment of 0xff sindie teh 0x10000 area?

Anyway, the data just seems to progress through the address space. So it's impossible to write the vector table first, then overwrite the reset vector, then fill the ram and then again write the proper reset vector.

One thing youne could try is whether the address space wraps around above 0xfffff. So you could perhaps write the vector table but without the final reset vector, then write the rest above 0x10000, then do some dummy writes to the rest of the address space until you wrap around to 0x00000 again, then write the reset vector.

Hi,

   Just to add a bit of clarification:  The USB BSL will start if the reset address is 0xFFFF and the device is being powered by USB.  This feature is not in the UART based BSLs, by default (in order to save power), but could be added by changing the low_level_init.s43 file.

Lane Westlund said:

This feature is not in the UART based BSLs, by default (in order to save power), but could be added by changing the low_level_init.s43 file.

Which low_level_init file do you mean? Of the application? Well if it is ever executed, it means that there IS code loaded and the reset vector points to it :)

What else does the MSP do if its flash is blank on devices with UART based BSL? Run wild? go into LPM? stay in reset state?

First: Thanks for both posts.

We ordered a sample 5438A and wanted to test the FFFFh@FFFEh with it. It has not arrived yet.

Jens-Michael Gross said:

@5c00
(code)
@ff80
(vector table data)
@0000
(0x10000 test data)
@fe00
(initialized data structure @0x1fe00)

 

I thought the flash goes from 4400h to 1C400h with the vector table data right in the middle of it.

So I imagined the txt-file as being a file with only one @XXXX statement and then code till the end statement.
If your version is right, then it should be easy to change the txt file at the appropriate location and place a ffffh there.
That would load the complete Code into the flash, but with a ffffh@fffeh.
The msp would start the bsl instead of the program in my understanding after a restart.

Jens-Michael Gross said:

This feature is not in the UART based BSLs, by default (in order to save power), but could be added by changing the low_level_init.s43 file.

Which low_level_init file do you mean? Of the application? Well if it is ever executed, it means that there IS code loaded and the reset vector points to it :)

What else does the MSP do if its flash is blank on devices with UART based BSL? Run wild? go into LPM? stay in reset state?

[/quote]

Probably the BSL430_Low_Level_Init.asm in the custom BSL sources.
If anyone has experience with this file, I would be very thankfull to see a code segment that makes the necessary change, because I know no asm.

Just to avoid any confusion in the above post, when I say "All MSP430s", I mean "All 5/6xx MSP430s"

Okay, thanks for the clarification.
When my sample arrives, I will change the BSL_Protect function and test this.