Comprehensive list of all 'Security Violation" reset sources

So in the midst of my own debug; I have further questions.  So technically I am testing on an MSP430F5308 (customer has F5328); but I think from the access violation and BSL perspective; not a big difference; but we're trying to instrument some stuff up and ran into a second problem (or at least a misunderstanding).  What I did was put the basic here: br here code in the RST code if I get the 0x0A (access violation) code in the SYSRSTIV register.  Coupled with this, we are watermarking the stack and saving off the last things we wrote to the DMA, so if we take the reset we can look back in RAM and see if we did something horrible to the DMA, and possibly a small bit of the call stack if I'm really lucky.  Well, I'd like to 'test' the code first, so I thought I'd try writing to address 0x1000, the BSL, to FORCE and error.  Problem is, it never takes the error, just blows right through.  Now it doesn't do the write (and I didn't unlock FLASH or anything, so I didn't expect it to); but it also doesn't seem to flag the error or force a reset.

I had SYSBSLC set to 0xC003- believing I have enabled the protection bit and for all 4 sectors of the BSL; including address 0x1000.  Now interestingly the SYSBSLOFF bit in that register also seems to have no effect; I see 0x3FFF no matter which state it's in; though my bigger issue is that SYSBSLPE doesn't seem to work- I never take the reset/NMI when I try to access protected memory.  Is there another register/bit I am missing to get protection to work?

(now note oddly this may not matter in the end- my customer is hitting the reset condition with 0x0A unintentionally; so we'll probably proceed without the SYSBSLPE bit thing resolved; but I'd like to understand if this is broken or not; because ultimately this may wind up being part of our fix/workaround).

radar said:

... the user’s guide is notoriously weak here. ...

I am not a TI Employee, in my opinion, it is not only the user's guide, and not only here that is weak. It is weak or simply incorrect in a lot of places in Data-sheets and Errata as well.

I do not know how to get technical information by watching videos, reading wikis, using face book, etc. Am I suppose to? TI seems to be strong in those areas. 

Okay, some minimal progress. I found that setting SYSBSLC to 0x800x, rather than 0xC00x will in fact enable 'protection' of the BSL area.  I hadn't actually seen the effect of bit 14 anyhow- the BSL section always reads 0x3FFF to me regardless of the state of this bit; so I think the description is lacking but at least I am able to trap the condition now for testing.  But the ultimate question still remains- what are all the possible sources of the Security Violation reset; so we can make sure to look at every one.

radar said:

...  I hadn't actually seen the effect of bit 14 anyhow- the BSL section always reads 0x3FFF to me regardless of the state of this bit; ...

How did you reach that observation/conclusion? Did you use actual code and made the CPU to change that bit and read the BSL section? Or, did you rely on some program in a PC and use JTAG to indirectly do that?

Despite of the fact that the PC program may be named "debugger", it might have hidden "features" that mislead you into erroneous conclusions.

Look a bit closer to the detail descriptions.

If the BSL area is protected, it is treated like vacant memory. Reading from or writing to vacant memory won’t trigger a reset, it may trigger an NMI, if VMAIE is set (vacant memory access interrupt enable). If not, it does nothing. Fetching an instruction from vacant memory (including protected BSL area) will trigger a PUC (but not a POR or BOR). So to trigger a PUC, you’ll have to jump to BSL area, not just to read it or write to it.

Thanks- that's good insight.  So I did find the 'empty space' ISR and at least checked for the flag.  In the end this is sort of a sidebar; the issue with testing the ISR was just so we could validate our capture code; in all honestly, the original thread here was to find all sources of the error; because we didn't actually have the BSL protection enabled.  This was just one way to get it to take that reset path and thus how we tried to test. 

Jens-Michael Gross said:

... About the registers, well, I’m not sure whether you can unprotect the BSL from user space. It’s possible that only BSL code running from protected BSL area can unlock the BSL or change the BSL configuration once it was protected. (the first 16 bytes of BSL area are not protected – they contain a jumptable to jump into BSL function, and once there, the CPU will be able to see the protected area) ...

I think otherwise. Try this:

#include "msp430.h"

void main(void)
{
  int *bslpt;
  int *rampt;
  WDTCTL = WDTPW|WDTHOLD;
  SYSBSLC = 0x0003;          // Try other values too!
  bslpt = (int *) 0x1000;
  rampt = (int *) 0x1C00;
  for (int i = 0; i < 1024; i++)
    *rampt++ = *bslpt++;
  while (1)
    P1IN;                    // Dummy read. Set a "break-poiint" here
}
// At "break-poiint", examing contents of BSL Flash @1000-17FF and
// the contents of RAM @1C00-23FF (which should be a copy of the above)