MSPM0G3507: NMI EXCEPTION (SRAMDED) caused by writing SRAM region

Hi,

I am responsible to integrate a FlashBootloader into our project which is based on a MSPM0G3507 MCU and I face a strange issue, see description below.

When I flash the BootManager via debugger, I get an exception at the initialization phase of some SRAM region (0x20001300).

I have an interface for init which is just go through one memory section in SRAM and writes some init pattern 4 bytes at a time(see below an example):

uint32 *MemoryPtr;
MemoryPtr = (uint32*)0x20001300;
while((uint32)MemoryPtr < SECTION_END)
{
	*MemoryPtr = INITPATTERN;
	MemoryPtr++;
}

So the start address for the init is 0x20001300 (SRAM). In the while loop (at first entry or after 1 iteration) I get an exception and I checked the registers, see below:

xPsr->EXCEPTION = 000010 -> NMI (Non-maskable interrupt)

SYSCTL_NMIIIDX->STAT = 0110 (SRAMDED)

SYSCTL_NMIRIS->SRAMDED = TRUE (SRAM double error detect)

Based on register values, I conclude that the exception is thrown because we have some ECC or Parity Check error when trying to write that SRAM area (see below the memory map for SRAM)

So, our address where the init fails is 0x20001300 which is inside Default subregion which has ECC and Parity Check applied.

To find out which of them is causing the exception, I moved my region from 0x20001300 to 0x20100000 (which is only Parity checked, no ECC). No exception is thrown, the initialization works as expected.

So, my conclusion is that we have some ECC error which triggers the NMI exception.

I analysed the issue with the company which implemented the FlashBootloader and they concluded that debugger somehow causes this issue, I will describe below.

I use my CCS Composer studio with TI XDS110 Debug Probe to flash the software on the PCB. After I flash the software I click "Resume(F8)" button to get the SW running. I go directly into Exception Handler, so SW is not behaving as expected.

Then, I change a little bit the debug  Program/Memory Load Options as following:

With this settings I flash again my BootManager software and instead of clicking "Resume(F8)" button, I press Reset button on my PCB and then the debugger connects to the SW running. This way I can avoid exception thrown on initialization phase. So debugger interfering with the memory operation to cause this NMI exception does make sense now. If I reset the PCB and attach the debugger to already running software is working, but connecting the debugger right after flashing the software doesn't work.

I have to mention that pressing reset button to be able to run the SW is only a workaround here, not a proper solution, therefore I am searching for a real solution.

Can you help me with this issue? Did you faced this type of behaviour before?

Please let me know if I have to provide more details, and I will try to do that as soon as possible.

Thank you in advance for your support!