• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 836 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler/LPSTK-CC1352R: #pragma NOINIT

Jo Gelie
Intellectual 570 points
Part Number: LPSTK-CC1352R
Other Parts Discussed in Thread: CC1352P, CC1352R

Tool/software: TI C/C++ Compiler

Hi,

I am trying to store a static variable within a non-initialized memory with the cc1352 like this:

#pragma NOINIT (_var)
uint32_t _var[10];

Everything seems to be fine from the memory map file (*.map):

.TI.noinit 
*          0    20008990    0000000a     UNINITIALIZED
                  20008990    0000000a     foo.obj (.TI.noinit:_var)

However, the startup code ignores my settings and initialize everything to zero.

Therefore, the cc135x technical Manual mention that:

SRAM Auto-Initialization
The SRAM can be initialized by dedicated auto-initialization hardware. All memory locations are initialized
to zero and the parity information is initialized as required.

now, I am confused.

How could we reserve a non-initialized area with the cc1352? 

Sincerely

  • 0
    TI__Guru**** 244950 points

    Jo Gelie said:
    the startup code ignores my settings and initialize everything to zero.

    Exactly what do you look at to know that happened?

    It would be ideal if I could see this problem in context.  Is this organized as a CCS project?  If so, please zip up the project as described in the article Sharing projects, then attach that zip file to your next post.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 570 points

    Hi,

    Environment:

    • simplelink_cc13x2_26x2_sdk_4_20_00_35
    • xdctools_3_61_01_25_core
    • LPSTK-CC1352 with battery
    • Debugger: XDS110

    Let's take the BLE simple_peripheral as an example.

    From the zip file, please take a look the noinit_test() function declared in application/noinit_test.c

    simple_peripheral_noInit_CC13X2R1_LAUNCHXL_tirtos_ccs.zip

    This function is called at the beginning of SimplePeripheral_taskFxn prior to any BLE initialization.

    Basically:

    1. I defined a global variable uint8_t _var[10] located within the TI.noinit section.
    2. I print _var[0] content
    3. I compare _var[0] content with the pattern 0xa5
    4. I set _var[0] to 0xa5
    5. I reset the board, so we go back to 2)

    Result expected:

    In 3) I expect to read 0xa5 from _var[0]

    Result obtained:

    I always read 0x00.

    Did I miss something?

  • 0
    Guru 92251 points

    Jo Gelie said:
    However, the startup code ignores my settings and initialize everything to zero.

    Section 9.5 SRAM Auto-Initialization of the  cc135x technical Manual contains:

    NOTE: The SRAM is auto-initialized during the system CPU boot sequence after a system reset.

    Therefore, it appears the cc1352 doesn't allow SRAM to be preserved across a reset.

    Someone else had the same issue - see Compiler/LAUNCHXL-CC1352P: #pragma NOINIT doesn't seem to work

  • 0 in reply to Chester Gillon
    Intellectual 570 points

    Hi,

    Well it's a shame that an advanced MCU could not handle basic linker instruction like initializing RAM retention area.

    Is there any alternative, or do we have to write to the flash to save one bit/byte across board reset?

    Thks

     

  • 0 in reply to Jo Gelie
    TI__Genius 10610 points

    Jo,

    The CC13x2 devices come with parity error detection. In order to avoid the device generating unwanted parity errors in uninitialized regions of memory, the SRAM is set to "0" on a reset. Section 9.5 of the TRM is correct in regards to this.

    The only "safe" way to save data through a reset is with flash.

    Regards,

    Daniel

  • 0 in reply to daniel_o
    Intellectual 570 points

    Hi Daniel,

    Actually I don't know how big is the stack for the m3Hwi.excHandlerFunc function called, I will reserve a NVS memory region, adding a wear leveling module for only saving core dump information before resetting.

    Therefore, in the case of stack overflow, both flash + wear-leveling access might be compromised making on the field debugging impossible (worst if the exception is causing by the persistent storage itself)

    Moreover, from the TRM, an SRAM parity error generates a Bus Fault Exception. At that point I am guessing that the SRAM is no more available, isn't it? 

    Thank you

  • 0 in reply to Jo Gelie
    TI__Genius 10610 points

    Jo,

    For more information about SRAM parity errors, please see sections 9.4 and 9.6 of the TRM. For information on exception types please see section 5.1.2.

    Regards,

    Daniel

  • 0 in reply to daniel_o
    Prodigy 70 points

    A large amount of embedded MCU applications rely on SRAM values to be maintained through a reset. 

    We are using the same chip(CC1352P) and trying to write a value in m3Hwi.excHandlerFunc so we can keep track of how many of our device resets are due to runtime exceptions. I'm attempting to implement a ~'last reset reason' status byte. Ran into this thread when I was searching how to do noinit RAM values. 

    Writing to flash in an exception handler doesn't seem safe. Any chance there is a work around for RAM? 

  • 0 in reply to Jo Gelie
    Guru 92251 points

    Jo Gelie said:
    Is there any alternative, or do we have to write to the flash to save one bit/byte across board reset?

    I did look at the cc135x TRM to see if there are any registers which are preserved across a reset, but all the registers seem to set to initial values by a reset.

    Note that I don't have a CC1352R to test this at the moment.

  • 0 in reply to Nathan Zimmerman1
    TI__Genius 10610 points

    Nathan,

    I think your best bet is going to be to write to flash since there's not a way to get around SRAM initializing on a reset. As long as you do simple NV writes in the handler you should be OK. There is some more information about using flash for storing logs here:

    https://processors.wiki.ti.com/images/2/27/DebuggingExceptions.pdf

    Additionally, you can use SysCtrlResetSourceGet() to get the reset reason. See more here:

     https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_20_01_04/docs/driverlib_cc13xx_cc26xx/cc13x2_cc26x2/driverlib/group__sysctrl__api.html#ga3f5b01e47c54408834611c9c2d7dc72f 

    Regards,

    Daniel