Hi Damon,

Yes there is, but as is mentioned in other threads, depending on the SDK (wireless protocol) being used Simplicity Studio was not designed for multiple build configurations and so the support for it is not complete.  If you right click the project folder and select [Build Configurations] > [Build All] it will build all of the configurations in the project.  For Bluetooth and other Project Configurator (.slcp file) based projects, you must first make each build configuration active and then open the .slcp file and do a [Force Generation].  If that is done for each build configuration then that configuration will build successfully and the Build All does build all of the configurations.

Note the Eclipse Build Set functionality is very powerful ([Project] > [Build Working Set] > [Select Working Set] to get started).  In a working set you can select the projects to include in the set and which build configurations for those projects.  So you could include all of the build configurations or you could have a "Debug" working set that only included all of the debug configurations from the selected projects.  Then [Project] > [Build Working Set] will build all of the configurations in that set.

I hope this information is helpful.

Thank you,

jpitt

Thanks jpit -- I somehow missed [Build Configurations] > [Build All]!

I will look into Build Sets.

GG11B4xx pin-out:

GG11B8xx pin-out:

T he EFM32GG11B8xx-GQ100 and EFM32GG11B4xx-GQ100 have the same footprint (QFP100) but slightly different pin-outs.

I am trying to make a PCB that will accept either part with suitable zero-ohm links.

On the GG11B4xx, Pin 59 = DECOUPLE and Pin 60 = PE0

On the GG11B8xx, PIN 59 = VSS and Pin 60 = DECOUPLE

I can connect Pin 59 to VSS or DECOUPLE with a zero-ohm link, but can I leave Pin 60 on the GG11B4xx connected to DECOUPLE, to save me one link?

I am laying out a PCB to support both the EFM32GG11B8xx-GQ100 and EFM32GG11B4xx-GQ100 parts.

Will there be a problem if the DECOUPLE pin is connected to a GPIO? I intend to set the GPIO Pin Mode to DISABLED. Will this work?

Hi John,

This is what I came up with:

MEMORY
{
	FLASH (rx) : ORIGIN = 0x0FE10000, LENGTH = 0x8000 /* 32k */
	RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x80000 /* 512k */
}


/* Linker script to place sections and symbol values. Should be used together
 * with other linker script that defines memory regions FLASH and RAM.
 * It references following symbols, which must be defined in code:
 *   Reset_Handler : Entry of reset handler
 *
 * It defines following symbols, which code can use without definition:
 *   __exidx_start
 *   __exidx_end
 *   __copy_table_start__
 *   __copy_table_end__
 *   __zero_table_start__
 *   __zero_table_end__
 *   __etext
 *   __data_start__
 *   __preinit_array_start
 *   __preinit_array_end
 *   __init_array_start
 *   __init_array_end
 *   __fini_array_start
 *   __fini_array_end
 *   __data_end__
 *   __bss_start__
 *   __bss_end__
 *   __end__
 *   end
 *   __HeapBase
 *   __HeapLimit
 *   __StackLimit
 *   __StackTop
 *   __stack
 *   __Vectors_End
 *   __Vectors_Size
 */
ENTRY(Reset_Handler)

SECTIONS
{
  .text :
  {

    *startup_efm32gg11b.o(.text*)

    *(.text*)

    KEEP(*(.init))
    KEEP(*(.fini))

    /* .ctors */
    *crtbegin.o(.ctors)
    *crtbegin?.o(.ctors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
    *(SORT(.ctors.*))
    *(.ctors)

    /* .dtors */
    *crtbegin.o(.dtors)
    *crtbegin?.o(.dtors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
    *(SORT(.dtors.*))
    *(.dtors)

    *(.rodata*)

    KEEP(*(.eh_frame*))
  } > FLASH

  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } > FLASH

  __exidx_start = .;
  .ARM.exidx :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  } > FLASH
  __exidx_end = .;

  /* To copy multiple ROM to RAM sections,
   * uncomment .copy.table section and,
   * define __STARTUP_COPY_MULTIPLE in startup_ARMCMx.S */
  /*
  .copy.table :
  {
    . = ALIGN(4);
    __copy_table_start__ = .;
    LONG (__etext)
    LONG (__data_start__)
    LONG (__data_end__ - __data_start__)
    LONG (__etext2)
    LONG (__data2_start__)
    LONG (__data2_end__ - __data2_start__)
    __copy_table_end__ = .;
  } > FLASH
  */

  /* To clear multiple BSS sections,
   * uncomment .zero.table section and,
   * define __STARTUP_CLEAR_BSS_MULTIPLE in startup_ARMCMx.S */
  /*
  .zero.table :
  {
    . = ALIGN(4);
    __zero_table_start__ = .;
    LONG (__bss_start__)
    LONG (__bss_end__ - __bss_start__)
    LONG (__bss2_start__)
    LONG (__bss2_end__ - __bss2_start__)
    __zero_table_end__ = .;
  } > FLASH
  */

  __etext = .;

  .data : AT (__etext)
  {
    __data_start__ = .;
    *(vtable)
    *(.data*)

    . = ALIGN (256);
    KEEP(*(.vectors))
    __Vectors_End = .;
    __Vectors_Size = __Vectors_End - __Vectors;
    __end__ = .;

    . = ALIGN (4);
    PROVIDE (__ram_func_section_start = .);
    *(.ram)
    PROVIDE (__ram_func_section_end = .);

    . = ALIGN(4);
    /* preinit data */
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP(*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);

    . = ALIGN(4);
    /* init data */
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);

    . = ALIGN(4);
    /* finit data */
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP(*(SORT(.fini_array.*)))
    KEEP(*(.fini_array))
    PROVIDE_HIDDEN (__fini_array_end = .);

    KEEP(*(.jcr*))
    . = ALIGN(4);
    /* All data end */
    __data_end__ = .;

  } > RAM

  .bss :
  {
    . = ALIGN(4);
    __bss_start__ = .;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
  } > RAM

  .heap (COPY):
  {
    __HeapBase = .;
    __end__ = .;
    end = __end__;
    _end = __end__;
    KEEP(*(.heap*))
    __HeapLimit = .;
  } > RAM

  /* .stack_dummy section doesn't contains any symbols. It is only
   * used for linker to calculate size of stack sections, and assign
   * values to stack symbols later */
  .stack_dummy (COPY):
  {
    KEEP(*(.stack*))
  } > RAM

  /* Set stack top to end of RAM, and stack limit move down by
   * size of stack_dummy section */
  __StackTop = ORIGIN(RAM) + LENGTH(RAM);
  __StackLimit = __StackTop - SIZEOF(.stack_dummy);
  PROVIDE(__stack = __StackTop);

  /* Check if data + heap + stack exceeds RAM limit */
  ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack")

  /* Check if FLASH usage exceeds FLASH size */
  ASSERT( LENGTH(FLASH) >= (__etext + SIZEOF(.data) - ORIGIN(FLASH)), "FLASH memory overflowed !")
}

It's similar to yours, but I place all the code in the Bootloader page by setting FLASH (rx) : ORIGIN = 0x0FE10000, LENGTH = 0x8000.

This is a stand-alone project, just for the Bootloader, so I don't need or want code anywhere except the BL page.

John, I obviously wasn't clear in my post...

I know that the the first instruction executed is at 0x0FE10000, and the difference between that and the vector table. I am trying to ensure that the linker places the very first instruction at that address.

I have located the vector table in RAM, and the startup code sets VTOR to point to it.

The above code seems to work. In Debug mode, the very first highlighted instruction at 0x0FE10000 is:

    ldr     r0, =SystemInit
    blx     r0

and the code at SystemInit is:

  SCB->VTOR = (uint32_t)&__Vectors;

...which is what I wanted.

I was just checking that there weren't any hidden "gotchas" in this approach.

I think this works:

  .text :
  {

    *startup_efm32gg11b.o(.text*)

    *(.text*)
.
.
.
} > FLASH

This puts the .text (i.e. code) from the Reset_Handler right at the beginning of the code section.

Are there any problems with this approach?