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.

AWRL6844: Warm reset retention memory selection.

Part Number: AWRL6844

Tool/software:

Hi expert,

I need to select a section of RAM in AWRL6844 to be used as retention memory, so that it continues to retain data after a warm reset.

Which block of RAM would be suitable for this purpose? How can we achieve this? Please give me some suggestions.

Thanks 

Rick

  • More specifically, the customer performs a warm reset by calling SOC_WarmResetWithoutEclipse() and wishes to retain the values of certain variables when the application is loaded during the warm reset.

  • Hey Rick,

    It would likely be best to use one of the DSS shared memories as these memories are not initialized by the RBL and shouldn't be cleared upon re-entering the RBL. Note: The application will be responsible for initializing the memory through SOC_memoryInit before use, and thus, uninitialized sections such as .bss should be used here.

    Assuming a single appimage is stored in SFLASH, you would assign .bss to DSS shared memory, power on the device and run the application which should initialize the DSS shared memory and then data is stored in .bss, SOC_WarmResetWithoutEclipse is triggered and application is reloaded, check that a warm reset was triggered and if so, do not initialize .bss again or else it will be cleared.

    For more information on how to utilize shared memory, they can refer to the Shared Memory Usage Example documentation from the SDK.

    Are they attempting to swap appimages? If so, it may be useful for them to review the SBL Lite Example under <MMWAVE_LSDK6_INSTALL_DIR>\examples\drivers\boot\sbl_lite.

    Let me know if any of this information is useful.

    Regards,

    Kristien

  • Hi Kristien,

    Using SOC_WarmResetWithoutEclipse for a warm reset still clears the shared memory. However, using SOC_WarmResetWithEclipse does not.

    It seems that the RBL is clearing or overwriting the corresponding RAM. The program is based on an empty project, so there is no application function to clear the memory. For example, SOC_memoryInit is not called here.

    What is causing this? Can you tell me more precisely which RAM is being used?

    The RAM areas we are using are as follows:

    Rick

  • Hey Rick,

    Upon reviewing the code further, the .bss section will always be zeroed out upon the program restarting. You can see in _c_int00 that we call _system_pre_init which sets the .bss memory to zero, effectively clearing it. You could remove this initialization, but this may cause unexpected behavior.

    Why exactly is the customer trying to retain data across the reset? Are they attempting to swap appimages and use data from one appimage in another appimage? Perhaps, there is another way we can work around these restrictions if I understand the intent behind these changes.

    Regards,

    Kristien

  • Hi Kristien,

    The customer's cold boot and warm reset execution SBL processes are different. Data needs to be passed between the SBL and the app to know which SBL processes need execution, so the relevant data must be retained.

    It seems that the .bss section is not being zeroed out. For some reason, the bss_size in _system_pre_init is always 0, and the addresses of __BSS_START and __BSS_END are the same. As shown in the figure below:

    It appears that the RBL has cleared the relevant RAM.

  • Hey Rick,

    I'm currently double checking internally on if there are other memories that could be potentially used here. Give me or two to receive feedback.

    Regards,

    Kristien