MSP430F5438 Security violation (BOR)

You get a BOR if you access secured areas like boot memory and so on.

Hm, I'm a little confused.

Is access to boot memory different than access to vacant memory (users guide p37: 1.11.1 Vacant Memory Space)  --> because this causes an SNMI and then a PUC and not a BOR?

There also stands that "After the boot code is executed, it behaves like vacant memory space and also causes an NMI on access"

Access to the boot memory is different.  The last few lines of the boot code enable boot code protection. So when you execute the boot code on power up, that area becomes protected. So from then onwards in your application if you perform any access (read/write) to that area, then you get a BOR

I have the same "Security violation" problem on the MSP430F5438A, how I can trace which code source access to this secured memory?

regards,

Mathieu

Which chip are you using? They behave differently.

In general, cause of reset is very difficult to track down. You may want to change your code and leave some clues in RAM "Hansel and Gretel" style. (Contents of RAM are not "reset" by hardware. But c-startup code may change them.)

I m using MSP430F5438A. Is there some interuption on this kind of violation, it could be easier, because code source is very big!!

Getting relevant info from TI about this may be challenging.

Alternatively, write new code which deliberately “violates” all kinds of “security” you can think of, and see what SYSRSTIV you get.

OK I found something, It resets since I have this code source for configure the mcu

#define F_CPU 16000000           

SetVCore(PMMCOREV_0);                     // Set VCore = 0
SELECT_FLLREF(SELREF__REFOCLK);           // Set DCO FLL reference = REFO
SELECT_ACLK(SELA__REFOCLK);               // Set ACLK = REFO
Init_FLL_Settle(F_CPU/1000,F_CPU/32768);
DISABLE_SVSL();
DISABLE_SVML();
DISABLE_SVSH();
DISABLE_SVMH();
SVSL_ENABLED_IN_LPM_FAST_WAKE();

instead of

UCSCTL1 |= DCORSEL2;
UCSCTL2 = FLLD_1+DCO_MULT;
UCSCTL6    |= XT2OFF;                        // XT2 is off. no division for MCLK and SSMCLK.

Any reasons?

I just had to troubleshoot a situation in which the device was being reset and SYSRSTIV was reading 0xA.

The reason was that I was modifying the DMAxSA, DMAxDA and DMAxSZ registers before turning off the DMAx (DMAxCTL.DMAEN = 0). I am using the DMA in repeated single-transfer mode with both source and destination addresses unchanged, so I am confident I was not accessing secured areas (like boot memory).

To fix it, I changed my code so the DMA is configured as follows and the problem disappeared:

1. DMAxCTL.DMAEN = 0
2. Set DMAxSA, DMAxDA and DMAxSZ with the appropriate values
3. DMAxCTL = DMADT_4 | DMADSTINCR_0 | DMASRCINCR_0 | DMAEN