Bad default configuration for ADuCM3029 DFP 3.1.0

Hello, 

This topic is more an report than a question.

I was facing problems when I write to the flash programs which use the hibernate mode of ADuCM3029. When the core wake-ups, some global variables get random values because they are allocated by the linker to memory regions that are not retained in the RAM.

I found a incompatibility between what stated in the Hardware Reference Manual of the device and what is implemented in the default linker register provided in the DFP 3.1.0.

The Manual states that:

"The SRAM start address is set to 0x2000_0000 and the stack pointer is set at 0x2000_2000. The stack will be written
from 0x2000_1FFF downwards. "

However, if a project is created in Cross Core 2.6.0 using the DFP 3.1.0,  and the memory map is generated, it can be found the information below about the memory region reserved for the stack:

 .stack         0x20000c00      0x400 RTE/Device/ADuCM3029/startup_ADuCM3029.o
                0x20004000                __StackTop = (ORIGIN (DSRAM_A) + LENGTH (DSRAM_A))
                0x20003c00                __StackLimit = (__StackTop - SIZEOF (.stack_dummy))

As can be seen, the stack region goes from 0x2000_4000 to 0x2000_3c00.

 

Moreover in the memory map file, it can be found that start address for the .data and .bss regions are located in the memory region which can not be retained (0x2004_0000 and over):

 *(.data*)
 .data          0x20040000      0x110 c:/analog devices/crosscore embedded studio 2.6.0/arm/gcc-arm-embedded/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7-m/rdimon-crt0.o
                0x20040008                __stack_base__
 .data.impure_data



.bss            0x2004054c       0xc8 load address 0x00000d24
                0x2004054c                . = ALIGN (0x4)
                0x2004054c                __bss_start__ = .
 *(.bss*)
 .bss           0x2004054c       0x1c c:/analog devices/crosscore embedded studio 2.6.0/arm/gcc-arm-embedded/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7-m/crtbegin.o

The memory division section of the default linker script is as follow, where DSRAM_A is used to map the heap and stack and DSRAM_B is used to map the .data and .bss regions.

MEMORY
{
  /* The first 0x180 bytes of Flash bank0 */
  FLASH0 (rx) : ORIGIN = 0x00000000, LENGTH = 0x180
  /* The remaining bytes of Flash bank0 */
  FLASH (rx) : ORIGIN = 0x00000180, LENGTH = 256k - 0x180
  /* SRAM bank 0+1 */
  DSRAM_A (rwx) : ORIGIN = 0x20000000, LENGTH = 16k
  /* SRAM bank 3 */
  DSRAM_B (rwx) : ORIGIN = 0x20040000, LENGTH = 16k
}

I think that would be better for default script if both regions (DSRAM_A and DSRAM_B) have retention capabilities, as in the example code below:

MEMORY
{
  /* The first 0x180 bytes of Flash bank0 */
  FLASH0 (rx) : ORIGIN = 0x00000000, LENGTH = 0x180
  /* The remaining bytes of Flash bank0 */
  FLASH (rx) : ORIGIN = 0x00000180, LENGTH = 256k - 0x180
  /* SRAM bank 0+1 */
  DSRAM_A (rwx) : ORIGIN = 0x20000000, LENGTH = 8k
  /* SRAM bank 3 */
  DSRAM_B (rwx) : ORIGIN = 0x20002000, LENGTH = 8k
}

This way, the user won't have mysterious problems related to variables' values of .bss and .data regions being lost during hibernate and the information about stack pointer provided in the Hardware Reference Manual will be matched as well.



Fix lack of conclusion in the comparison between stack region of Reference Manual and Linker Script
[edited by: luis.possatti at 5:32 PM (GMT 0) on 10 May 2019]