MSP432E401Y: What will happen to RAM on software reset?

Hi Dinkar,

If you were to reset your program by calling SysCtlReset(), then you will the same memory block allocated to *test. This is since TIRTOS will reinitialize itself and reset its entire state, including the state of allocated heap memory, once you run BIOS_start() from main(). This is regardless of whether the RAM state is retained or not, since all of your code is placed in flash during linking by default. 

Given the compiler should only use RAM for temporary storage of data, it shouldn't matter to your code once it resets whether the RAM was in a non-reset state. The RAM is used for automatic allocation of data for the stack which is routinely reused by the program as data goes in and out of scope. It is also used for dynamic allocation of data which as explained above doesn't require the state of RAM to be fully clean, since the RTOS will reinitialize its heap memory table.

You can test this behavior for yourself by running the following test code in the mainThread() of your program:

        //memory/reset testing
        volatile int i =0;
        while(i==0);
        int* y;
        y = (volatile int*)(0x20000000+0x00040000-250);
        *y = 0x3010;
        someHeap = (int*)malloc(400);
        while(i==0){

        }
        SysCtlReset();

You will need to adjust the memory map of your program in your .cmd file like so to be totally safe:

MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00100000
    SRAM (RWX) : origin = 0x20000000, length = 0x00040000-250
    SRAM_EX (RWX) : origin = 0x20000000+0x00040000-250, length = 250
}

If you run that code you will get stuck at the first while(i==0). However, in debug mode you can point the PC to any executable instruction, and you can use that functionality to jump over the while(i==0) loops. If you jump to the second section, you'll see that the RAM is written and the malloc called to give a pointer to someHeap. Once you have recorded the heap memory address for reference, you can jump to the SysCtlReset() call. That should bring you back to the first while loop. At this point, you can check to see the data previously written to the address y to verify that the RAM was not reset. Then, if you jump back to the malloc, you'll observe that despite the RAM being fully retained, the RTOS will give someHeap the same memory block as the first iteration pre-reset.

Let me know if you need more clarification on the explanation above, or if you have further questions on SysCtlReset().

Regards,
Michael