CCS V5.3 "Allow read/write/erase access to BSL memory"

Tim Good said:

Technically you can always read this memory

Not really. Once the protection got enabled, the BSL memory are can only be accessed by a data or instruction fetch when the program counter points to BSL as well. So of course the BSL itself has access to its own area. But the JTAG, which also uses teh normal memory bus to perform read and write operations, or any running applicaiton code, does NOT have access to this memory area.

I dont believe any protection nas been enabled; evidence: the MSP430flasher tool can program the device and program the BSL area :-)

It is CCSstudio which cannot despite the "Enable read/write/erase BSL" tick box in the MSP430 debug settings being set!

It can read (with the check box set) just cant write (and to prempt the next post the BSL area was already erased - returned 0xffff's).  As a point of information if the memory was unreadable it would return 0x3fff.  As pictures speek louder than words attached is screen dunp showing CCSsrtudio reading the BSL area (loaded BSL via MSPflasher with -b option).  Wnat I need to do is find a way of writing / debugging custom BSL with CCSstudio i.e. how do I get the "enable BSL read/write/erase" check box to work?!

Tim Good said:

I dont believe any protection nas been enabled; evidence: the MSP430flasher tool can program the device and program the BSL area :-)

Well, "protection" doesn't mean "no way back". The protection is done using the SYSBSLC register. As long as this register is writable, the protection can be removed. By JTAG or other code.
The problem is the SYSCTL register. In it is the SYSPMMPE bit. Once this bit is set, the PMM registers are write protected until BOR. Access to them is restricted to code that executes from within BSL area. However, the boot code usually doesn't set this bit, leaving SYSBSLC open for changes.

I was denying your statement that 'technically you can always read BSL memory". No not always. However, apparently the debugger clears the protection bit, making the BSL area readable. Which works because neither boot code nor BSL entry-sequence check have activated the config register protection (2nd protection layer).

Now I don't know what's the problem: If you can read BSL memory (SYSBSLPE bit clear), BSL memory an be erased and programmed like any otehr (except that it isn't part of a mass erase). So I don't know why CCS should have problems writing it.

Some possible reasons:

- The boot code sets SYSBSLPE and while the debugger clears it for memory read, it doesn't clear it at programming time.
- the debugger performs a mass erase at progtramming time but fails to perform an individual segment erase on the BSL area, so the are appears 'erase-proof'.
- the 54xx (non-A) devices were generally unable to write to the BSL area and hte debugger doesn't notice that the A versions are.

Tim Good said:

Wnat I need to do is find a way of writing / debugging custom BSL with CCSstudio i.e. how do I get the "enable BSL read/write/erase" check box to work?!

Try a direct SYSBSLC register manipulation. Maybe...

Indeed it would appear to be a problem with the commands that CCSstudio sends to the debugger (MSP-FET430UIF).  I dont have the source for either; it is wholly within TI's gift to look at why their tool with their debugger cannot write to the BSL area of their silicon.  I would suggest someone hooks up a MSP430F5435A part via the MSP-FET430UIF (revision 1.4a), and tries to download the Custom BSL example code to it (techically the latest release of the compiler 4.1.5 doesnt quite optimise it down enough so it is a few bytes too many for the BSL area but I am sure you'll manage)...

You may have hit the nail on the head in that there is a mis-detection of the device capaility (i.e. FLASH BSL rather than ROM BSL), howver, on an FRAM part I am also using the tick box is grayed out so I would have thought that being able to tick it indicates the tool believes that there is BSL flash there.

As to manipulating any regisisters directly....that is only something that the developers of CCSstudio can do!

I dont beleive there was ever an erase issue as the original devices I had always reported, when read in CCSstudio) 0xffff in the boot area (indicating that they were already erased) - 0x3fff would have been reported if inaccesable.

Hopefully, someone will pick up this issue with CCSstudio (V5.3) and clarify why it cant write to the BSL area!