MSP430F5310: Customising the BSL

One more point:

6. I was able to download the BSL project and by configuring the debug / flash setup I was able to download the BSL to flash. I could go through my added CRC function by changing the PC value once it reached main(). However, when I attempted to single step through any BSL access related line for example

BIS #SYSBSLPE+SYSBSLSIZE0+SYSBSLSIZE1 , &SYSBSLC ; protects BSL

This caused the debug interface to lock up again and I lost a part.

Problem is that JTAG fuse value is stored inside last BSL flash segment, at 0x17FC to 0x17FF. Default factory (JTAG unlocked) value is 0xFFFFFFFF. JTAG will be unlocked also with fuse value 0x00000000. Whit any other fuse value (probably overwritten by increased size of your customized version, check 0x17FC value in generated binary), JTAG will be locked, and with erratic BSL in the same time, device will be bricked. If you can write four zero bytes at 0x17FC (no need to erase anything, just write) with your BSL on JTAG locked device, they should be unlocked.

When I was working on my BSL, I used only main flash. On power up / reset device start executing BSL code from main flash like any other program. BSL was copied to RAM and executed there, and main flash was erased and ready for update. At the end of development, when I was 100% sure that everything is working fine, I relocated BSL from main flash to BSL flash area. Finished project with zero bricked devices. BSL still was copied to RAM end executed there.

If I remember right, BSL is some kind of special flash area where breakpoint debugging is not supported (not related to BSL protection bit/s).

Hello,

Thanks for the reply!
I've checked the location 0x17FC - 0x17FF and they are fine, there is no overflow of memory onto these areas and they are still 0xFFFF at least in the binary TXT file.

You mentioned writing four zero bytes to 0x17FC using my own BSL, but as the JTAG is locked I have no way of flashing a new BSL onto the device. Please can you explain how to do this? Can I use the working BSL to flash a new BSL or modify these flash locations?

Many years ago you had posted some scripts to do the unlock, please can you post them here? That old post has dead links and I could not get the script. I am referring to this location you had posted: http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=44019

Thanks,

Arun

If your (or TI factory preloaded) BSL on JTAG locked device is functional, you can use it (BSL) to write four zero bytes at 0x17FC with ti txt file (value at 0x0182 is used to unlock BSL flash segments) ...

@182
03 00
@017FC
00 00 00 00
q

If BSL on JTAG locked device is non functional, than device is bricked.

Hello,

I tried this on a bunch of my bricked ICs and in all of them the BSL comms actually went through fine, so I know the BSL works. I've also tested by other means that BSL works in all of these.

However, this did not result in the JTAG getting unlocked. I was half expecting this, because my code never wrote to flash, nor did the memory exceed so that the 0x17FC - 0x17FF memory was changed from all FFs. My linker control file also would have reported this issue.

Thanks a lot for your help.

But I'm now down to my last part and still no idea how the bricking is happening. I've unit tested the CRC code on an application space project and it works fine. So I am suspecting something else is the root of the issue. Even if I order more parts I don't know how to avoid bricking all of them too.

For example is it okay for other registers R13,R14,R15 to be used/changed in the BSL_Protect function?

Can BSL_Protect function use stack?

Thanks,

Arun

If I remeber right unlocked BSL (flash segments) read will return zeros. So if your BSL is working OK and flash segments are unlocked, than first read of 0x17FC should return 0xFF values. After re-write with zeros, read of 0x17FC should return 0x00.

Sometimes JTAG master can report blown JTAG fuse even fuse value is untouched (factory default). I found this in case of flashing device with erratic firmware. This state was cleared with BSL mass erase, or leaving device for few hours to "cool down".

R12 is used as returning value in BSL Protect function.

Hello,

I've now locked the last part I had too, and I still don't know what the reason is. I've got rid of some other doubts for example I do not use stack any more and I am not calling the CRC as a function but as assembly.

The BSL still works as I can load new applications to the part without any problem.

I'm pretty sure now that all these parts have got locked because I am violating some rule which applies to the BSL_Protect function. For example, I am using R13,R14,R15 as scratch registers and I am returning the return value in R12 as you have mentioned.

Is there some restriction on:

- How big BSL_Protect is? I am making sure via linker file that the overall BSL fits into the required 2KB size and the values in 0x17F0-0x17FF are correct.

- Can BSL_Protect use R13/R14/R15?

This is now reaching emergency levels, I hope someone in TI can help!

Thanks,

Arun

Hello,

I did find one interesting paragraph in SLAA450G:

The BSL Protect function is called with the stack pointer set to a default location, which is dependent on the device. Changing the stack pointer or manipulation of the stack pointer data values will most likely lead to a unresponsive device. In this case, nothing, not even reprogramming, will be possible. On some devices, the stack pointer space is very limited, and extensive use of the stack pointer within the BSL Protect function could lead to memory overflows. To ensure proper behavior, the stack access should be limited or the stack pointer should be moved to another location. To make sure that the device returns from the BSL Protect function correctly, the stack pointer must be restored before returning.

So this confirms it's not a good idea to use SP. I have learnt this by trial and error and am not using it any more.

However it does not say anything about R13/R14/R15 usage.

Another interesting paragraph is:

Excessively long delays in the return functions could lead to problems during debug. At its most basic, the BSL Protect function should perform two essential operations: protect the BSL memory and determine whether the BSL or user code should be executed after exiting the BSL Protect function

But it is not very specific. For example is a CRC loop considered too much of a delay?

Thanks,

Arun

I just check my CDC BSL for MSP430 devices with USB hardware module. Protect function is about 10 assembler instructions in total, protecting BSL and checking PUR. Didn't use any other registers in it, except R12.

If your BSL is working fine on bricked devices and you can update main flash, you can write simple program for main flash that will unlock and erase all bsl segments, and mass erase main flash. Totally erased device (BSL & main) should work with JTAG just fine. Than you can write back original factory BSL, and start again.

Hello,

Thanks for the suggestion, I will try it.

But still the issue of why the JTAG gets locked is not solved. Unless I figure that out I'm sure to brick more devices.

The only thing I can think of is that I should not use R13/R14/R15 or should use and restore them. I will try that when I get new parts to work with, I've ordered them.

Thanks,

Arun

Hi Arun,

Do you need other support for this issue?

Thanks!

Best Regards

Johnson

Hello Johnson,

Yes please, I'd like some help to find out what I might have been doing wrong to brick so many chips' JTAG.

I am getting a new batch of 6 MSP430F5310 tomorrow and I will try some ideas but really I am down to two ideas:

- save/restore R13/R14/R15 that are used in my CRC loop so they are preserved across BSL_Protect

- could the extra time taken for the CRC loop be causing an issue e.g. watchdog or something?

Specific advice on this issue would be very welcome!

Thanks,

Arun

Update:

I received new ICs and tried the above two ideas in one go and now the bricking problem is gone!
So it seems one or both of above guesses was right.
It will be good to get a confirmation from TI on which is necessary so I do not brick any more JTAGs trying to isolate the issue.

Thanks,

Arun

Hi Arun,

Let me check with BSL expert then feedback to you for this root cause.

Thanks!

Best Regards

Johnson