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.