How to set wakeup restore address?

Sample code peripheral_server_sleep (sdk 3.3.0.75) set the wakeup restore address as follows (in case NOT LIGHT stack):

    /* Set wake-up restore address */
    sleep_mode_init_env.wakeup_addr = (uint32_t)(DRAM2_TOP + 1 -
                                                 POWER_MODE_WAKEUP_INFO_SIZE);

i.e. (0x20005FFF + 1) - (6*4) = 0x20005fe8, which is basically at the end of DRAM[2].

Several questions arise:

  1. why is this address?
  2. should this be always the case?
  3. what if flash overlay (say PRAM[0:3]) is enabled?

Edit: I notice the following in the sections.ld of sample MFi_hearing_aids,

    .data  : AT ( __data_init__ )
    {
        . = ALIGN(4);

        /* This is used by the startup code to initialize the .data section */
        __data_start__ = . ;
        *(.data_begin .data_begin.*)
        *(.data .data.*)
        *(.data_end .data_end.*)

        /* Place sleep and wakeup routines in retention RAM
         * Wakeup_From_Sleep_Application_asm has to followed directly by
         * Wakeup_From_Sleep_Application */
        *(.app_wakeup_asm)
        KEEP(*(.app_wakeup))
        KEEP(*(.sys_powermodes_wakeup_2mbps))
        /* Sys_PowerModes_Sleep is placed in retention RAM here, but it can
         * also be placed in flash to save some RAM space. To do this,
         * comment out the following line and add FLASH_POWER_ENABLE to the
         * sleep_mode_env->mem_power_cfg variable. */
        *(.sys_powermodes_sleep)

        . = ALIGN(4);

        /* This is used by the startup code to initialize the .data section */
        __data_end__ = . ;
    } >DRAM

  1. why is this address?
  2. should this be always the case?
  3. what if flash overlay (say PRAM[0:3]) is enabled?
  1. This address appears optimal since it sits at the top of the Data memory which is typically where the stack would sit. Placing it hear and then putting the stack just below it in memory leaves the rest of RAM available as a contiguous block.
  2. The wakeup address can be relocated, but the ROM limits the choices. Table 6 on pages 56 and 57 of the Hardware Reference Manual lists the allowable choices. Note that if it is relocated to another memory, the memory retention power options should be modified to ensure that memory is retained during sleep.
  3. Enabling flash overlay does not affect the retention status of the PRAM[3:0] blocks, it only makes them read accessible via the correspond overlay FLASH address in addition to their read/write address in their main memory map location. So yes they could be used for sleep retention with the overlay enabled. However that would seem to defeat the purpose of overlaying the PRAM with the Flash as that feature is intended to be used by copying the FLASH into the PRAM, then overlaying the PRAM with that same content allowing the routines in FLASH to execute faster out of PRAM. Putting something other than the FLASH code into the PRAM then overlaying with the FLASH has questionable value unless perhaps you’re looking to effectively overlay only a portion of the FLASH with one of the PRAM blocks and use the rest as the sleep retention RAM.

If it helps I attached a copy of the memory map with the areas being discussed highlighted to make following the discussion easier.

@jamie.meacham Edit 1) If the calculation is correct, this address is 0x2000 5FE8 (with DRAM2_TOP =
0x2000 5FFF according to the sdk code), which is DRAM2_END (i.e. end of DRAM[2]
and not DRAM2 = 0x2180 6000 ref. Figure 8 RSL10 Hardware Reference). None the
less, as you mentioned, it is one of the allowed addresses (Table 6 RSL10
Hardware Reference).

In the following, I would like to describe what is my understanding of Sleep
Mode.

First of all, the application may wake up either from Flash or RAM.
If the application is willing to wake up from RAM then the application
shall set (in relation to the wakeup restore)

<1 set ACS->WAKEUP_CTRL |= BOOT_CUSTOM;
<2 set SYSCTRL->WAKEUP_ADDR to one RAM address limited to one of the addresses
of Table 6 (e.g. DRAM2_END);
<3 write the wakeup routine address (e.g.&Wakeup_From_Sleep_Application_asm) to
SYSCTRL->WAKEUP_ADDR + 0x14 (i.e. last 32 bit of DRAM[2]);
<4 place the wakeup routine (e.g. .section .app_wakeup_asm) in the defined RAM
address (i.e. DRAM2_END) as per linker script, and
<5 update ACS->WAKEUP_GP_DATA with 7-bit packed version of SYSCTRL->WAKEUP_ADDR
and the memory power (or access?) configuration with DRAM[2] enabled.

That is to say,

1> wake up from RAM,
2> define which RAM region to wake up from,
3> define which wakeup routine to call when back from sleep,
4> store wakeup routine in RAM,
5> keep RAM region alive.

Please, let me know if my description is incorrect or there is something to remark.

@darrew
Hi could you please let me know where I can view or download the MFi_hearing_aids sample code? Is it available in SDK 3.5 for RSL10?

Is this also RSl10 SDK? Is it available in onsemi website?

I believe you’ve summarized the process well. As to the wake address, there’s a note in the Hardware Reference Manual that the wakeup restore address must be either the first address of a RAM instance or the last address minus 20. That’s where the addresses in Table 6 come from.

@mahaju There isn’t an MFI example in the RSL10 SDK.

For products with MFI support I suggest contacting your local onsemi sales representative. There’s a bit more information in this topic: Is an RSL10 sample application for streaming audio to iphone available?

2 Likes