This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC1312R: Prevent/disable initialization of SRAM to 0 on boot/resets

Part Number: CC1312R
Other Parts Discussed in Thread: CC1310,

Tool/software: TI-RTOS

We have a problem with CC1312R initializing SRAM to 0. On CC1310 one could exclude portions of SRAM from the linker cmd file, or mark variables with #pragma NOINIT and the compiled firmware would not initialize that memory to 0 upon boot.

If we do the exact same with CC1312R, the variables end up being zero-initialized anyway. We need certain critical data in SRAM to survive reboots. How would we go about achieving this on CC1312R?

How to replicate on CC1312R:

  • (using CCS 9.0.1.00004, building with XDCtools 3.51.2.21_core and SimpleLink CC13x2 26x2 SDK 3.10.1.11 for platform ti.platforms.simplelink:CC1312R1F3)
  • download and install uartecho_CC1312R1_LAUNCHXL_tirtos_ccs and tirtos_builds_CC1312R1_LAUNCHXL_release_ccs from Resource explorer
  • modify uartecho.c such that before mainThread(...), this is inserted: 
#pragma NOINIT (var)
volatile uint32_t var;
  • further modify this file such that after UART_write(... echoPrompt ...) inside mainThread(...), this is inserted:
var++;
char t[16]; int n = snprintf(t, 16, "%d\n", var);ž UART_write(uart, t, n);
  • build and upload firmware.
  • keep reseting the device. The additional number that is written to UART, is expected to start at an arbitrary value, and should increase after each reset. However, the value is always 1, suggesting that the value gets 0-initialized despite being instructed not to, by the #pragma.

Check the code on CC1310

  • (using CCS 9.0.1.00004, building with XDCtools 3.51.2.21_core and SimpleLink cc13x0 SDK 3.10.0.11 for platform ti.platforms.simplelink:CC1310F128)
  • download and install uartecho_CC1310_LAUNCHXL_tirtos_ccs and tirtos_builds_CC1310_LAUNCHXL_release_ccs from Resource explorer
  • do the exact same modification as above to uartecho.c
  • build and upload firmware.
  • keep reseting the device. The number increases as expected.

  • Hi,

    The CC13xx devices are not designed to retain RAM content through a reset. Even though it is possible to not initialise RAM to a set value in some cases, it does not mean the content of RAM can be trusted. 

    The only safe way to store data through a reset is by storing it in flash.

    Regards,
    Fredrik, 

  • We are aware of the pitfalls of relying on SRAM data through resets and we are handling them in our application. The types of data is changed too often for the chip's flash to be suitable for this.

    We've already made a working solution with CC1310, but we need more program strorage, so CC1312R would be a perfect solution for this since it allows direct replacements.

    CC1312R seems to zero-initialize the entire RAM on boot, regardless of linker cmd file settings or #pragma instructions. CC1310 honors them. Is there a way for CC1312R to do the same?

  • Hi,

    There is no issues with the pragmas as such, your variables are placed within the "No init" section. What is the "pitfall" in your case is that the new platform comes with parity error detection. To make sure the device do not generate parity errors due to reading uninitialized regions, the hardware resets the SRAM to zero during the boot process.

    This is expected behavior and nothing you can override, the SRAM will reset to "0" during a reset (this behavior is noted in the Technical Reference Manual, chapter 9.5) to ensure propper parity error detection support.

    Best regards,

    Max