MSP432 SRAM memory retention with hard system reset

Ok, thanks for the info.

My part is not retaining this memory through the software-initiated hard (or soft) reset, so I believe it is an issue with the REV B part, perhaps related to:
e2e.ti.com/.../486445

I will need to get the REV C silicon and retest.

-Aaron

I am now testing with MSP432P401R rev C and having the same issue! The SRAM contents are maintained through an LPM3 sleep and wake.
But then I call ResetCtl_initiateHardResetWithSource(#). When the MSP comes back up, the SRAM1 contents are all cleared.

How can this be happening?

Here's the code that executes on GPIO-initiated wake:
void wakeOnGpioISR()
{
uint64_t status;

// Handle PORT2
status = MAP_GPIO_getEnabledInterruptStatus(GPIO_PORT_P2);
MAP_GPIO_clearInterruptFlag(GPIO_PORT_P2, status);

// Handle PORT3
status = MAP_GPIO_getEnabledInterruptStatus(GPIO_PORT_P3);
MAP_GPIO_clearInterruptFlag(GPIO_PORT_P3, status);

MAP_Interrupt_disableInterrupt(INT_PORT2);
MAP_Interrupt_disableInterrupt(INT_PORT3);

ResetCtl_initiateHardResetWithSource(HARD_RESET_BITCODE__NORMAL_RUN);
// Thus the MSP resets and RESET_SRC value is detected on wake

// A breakpoint test indicate that this is unreached code, as expected
while (1) {}
}

If I set a breakpoint in the code above, I see the SRAM contents are still present.

If I set a breakpoint at the first line in main(), the contents are all cleared.

Here's my setup code, later in main():
// Wait until ready
while (!(SYSCTL->SRAM_BANKEN & SYSCTL_SRAM_BANKEN_SRAM_RDY));
// Enable only SRAM banks 0 and 1
SYSCTL->SRAM_BANKEN = SYSCTL_SRAM_BANKEN_BNK1_EN;
// Wait until ready
while (!(SYSCTL->SRAM_BANKEN & SYSCTL_SRAM_BANKEN_SRAM_RDY));
// On sleep, retain only SRAM banks 0 and 1
SYSCTL->SRAM_BANKRET |= (SYSCTL_SRAM_BANKRET_BNK0_RET | SYSCTL_SRAM_BANKRET_BNK1_RET);
// Initialize ap_data_buf, which is in bank1 (of 0..7)
if (main_globalRunState == RUN_STATE__FIRST_TIME)
{
int i;
for (i=0; i< AP_DATA_STORAGE_SIZE_IN_DWORDS; i++)
ap_data_buf[i] = 0xA0A0;
}

As Clemens mentioned earlier, the C startup code will reinitialise .data and .bss when it runs. This will happen before execution reaches main(). To see if this is the cause of your issue you could set a breakpoint earlier in the startup process.

Thanks guys.  Those commands look useful, but I have already setup my code to put my array, ap_data_buf[], into a seperate section.

Do you see anything suspicious here?

Thanks,

     Aaron

 

--retain=flashMailbox

MEMORY
{
MAIN (RX) : origin = 0x00000000, length = 0x00040000
INFO (RX) : origin = 0x00200000, length = 0x00002000 /* Reduced to include only bank 0 (of 0-7) allocation */
SRAM_CODE (RWX): origin = 0x01000000, length = 0x00004000 /* Was: SRAM_CODE (RWX): origin = 0x01000000, length = 0x00010000 */
SRAM_DATA (RW) : origin = 0x20000000, length = 0x00002000 /* Was: SRAM_DATA (RW) : origin = 0x20000000, length = 0x00010000 */
SRAM_AP_DATA (RX) : origin = 0x20002000, length = 0x00002000 /* Added for bank 1 (of 0-7) allocation */
}

SECTIONS

{
.intvecs: > 0x00000000

.text : > MAIN
.const : > MAIN
.cinit : > MAIN
.pinit : > MAIN
.init_array : > MAIN

.flashMailbox : > 0x00200000

.vtable : > 0x20000000
.data : > SRAM_DATA
.bss : > SRAM_DATA
.sysmem : > SRAM_DATA
.stack : > SRAM_DATA (HIGH)

.ap_data : > SRAM_AP_DATA /* Added for bank 1 (of 0-7) allocation */
}

/* Symbolic definition of the WDTCTL register for RTS */
WDTCTL_SYM = 0x4000480C;

I forgot to add, the declaration of ap_data_buf[] in my c code specifies the section:

// Allocate AP storage. 8196 bytes = 0x1000 16-bit values
#define AP_DATA_STORAGE_SIZE_IN_DWORDS 0x1000
#pragma DATA_SECTION(ap_data_buf, ".ap_data")
uint16_t ap_data_buf[AP_DATA_STORAGE_SIZE_IN_DWORDS];

Aaron,
Thanks for following up and posting your findings. For others who find this thread in their search here is also a link which describes the NOLOAD special section type: www.ti.com/.../spnu118p.pdf. This is taken from page 229 of SPNU118 revP.

Regards,
Chris