AWRL6432: AWRL6432 lowpowercfg 1 with SH_MEM_CONFIG=3

Part Number: AWRL6432
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

My customer wants to use deep sleep mode with SH_MEM_CONFIG=3, but the code enters hard fault after wakeup from deep sleep mode.

I found APPSS_SHARED_MEM_CLK_GATE value is incorrect after wakeup. I added the code at the beginning of power_LPDSresumehook to reconfigure APPSS_SHARED_MEM_CLK_GATE to correct value. But the code still can't work.

Would you pls kindly advise how to using deepsleep mode with SH_MEM_CONFIG=3?

Thanks,

Chris

  • Hey Chris,

    What clusters are set for the RAM retention mask in the SysConfig power driver? Please ensure that none of the data needed for operation in a subsequent frame, such as device code or global variables, is stored in RAM clusters that are not retained. If this occurs, it will prevent proper operation, as the information the device needs to operate will have been erased - see figures below taken from Power Optimization Techniques app note. Note: A quick test to verify if memory retention is the issue would be to enable all RAM clusters to ensure that no data is loss during deep sleep.

    Regards,

    Kristien

  • Kristien,

    After I added HWA_PD_SRAM_CLUSTER_3, the code can work ok now. Would you pls kindly explain why? HWA_PD_SRAM_CLUSTER_3 is not needed to retain when SH_MEM_CONFIG=0. 

    My test code is based on motion and presence detection demo in SDK5.5. cfg: PresenceDetect.cfg

    cmd:

    SECTIONS
    {
    /* This has the M4F entry point and vector table, this MUST be at 0x0 */
    .vectors:{} palign(8) > M4F_VECS
    .bss: {} palign(8) > M4F_RAM12 /* This is where uninitialized globals go */
    RUN_START(__BSS_START)
    RUN_END(__BSS_END)
    .text: {} align(8) >> M4F_RAM33| M4F_RAM12 | M4F_RAM3 /* This is where code resides */
    .data: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where initialized globals and static go */
    .rodata: {} align(8) >> M4F_RAM12 | M4F_RAM3 /* This is where const's go */
    .sysmem: {} palign(8) > M4F_RBL /* This is where the malloc heap goes */
    .stack: {} palign(8) > M4F_RBL /* This is where the main() stack goes */
    .l3: {} palign(8) > HWASS_SHM_MEM /* This is where L3 data goes */
    }

    MEMORY
    {
    M4F_VECS : ORIGIN = 0x00400000 , LENGTH = 0x00000200
    M4F_RAM12 : ORIGIN = 0x00400200 , LENGTH = (0x00058000 - 0x200) /* 32KB of RAM2 is being used by RBL */
    M4F_RBL : ORIGIN = 0x00458000 , LENGTH = 0x8000 /* 32KB of RAM2 is being used by RBL */

    M4F_RAM3 : ORIGIN = 0x00460000 , LENGTH = 0x00010000

    M4F_RAM33 : ORIGIN = 0x004B0000, LENGTH = 0x00010000 

    HWASS_SHM_MEM : ORIGIN = 0x60000000, LENGTH = 0x00040000 
    }

    map:

    MEMORY CONFIGURATION

    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    M4F_VECS 00400000 00000200 00000140 000000c0 RWIX
    M4F_RAM12 00400200 00057e00 00057dfb 00000005 RWIX
    M4F_RBL 00458000 00008000 00004000 00004000 RWIX
    M4F_RAM3 00460000 00010000 0000a168 00005e98 RWIX
    M4F_RAM33 004b0000 00010000 00010000 00000000 RWIX
    HWASS_SHM_MEM 60000000 00040000 00040000 00000000 RWIX

    Thanks,

    Chris

  • Hey Chris,

    I had originally thought this might be an issue with minor motion data needing to be retained across frames, but its strange that the behavior changes whether the SH_MEM_CONFIG is 0 or 3 as the size of the HWA should not affect the behavior in that case. Were there any other changes made to code or was only the linker and SH_MEM_CONFIG adjusted?

    Regards,

    Kristien

  • Were there any other changes made to code or was only the linker and SH_MEM_CONFIG adjusted?

    One more change is to reduce the radar cube size to 256KB. No other changes.

    Would you pls help to explain why HWA_PD_SRAM_CLUSTER_3 need to enable retention in this case?

    Thanks,

    Chris

  • Hey Chris,

    I'm still unsure as to why HWA_PD_SRAM_CLUSTER_3 needs to be retained in this case, as it should only contain L3 memory that is non-critical for deep sleep recovery. Could you verify what is the size of L3, how much is used, and how much is free by checking for the Memory Stats printed out to the debug console upon starting the sensor? Could you also include the generated .map file if possible?

    Regards,

    Kristien