scatter file

LOL - must be an interesting story hidden there somewhere.

Thanks to all of u.

kindly tell me, how can i create scatter. give me any example and how can i transfer this scatter file to linker.

Thanks

a scatter file is available for many uv3 projects (a default one is provided; access it through the target settings/linker dialog).
It is a simple text file. Here is an example:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

; Application code always starts at 0x28000 and has a maximum allowed size of 0x56000 bytes (344 KB)
; so that it can theoretically strech from the begining of sector 12 until the end of sector 27

LR_IROM1 0x28000 0x56000  {    ; load region size_region
  ER_IROM1 +0 0x1000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  SOFTWARE_EVENT 0x29000 FIXED 0x60 {; this region is used to export the software event function for quick invocation
                                                                         ; by the firmware in case of a failure
        SOFTWARE_EVENT.o (+RO)
  }
  SIGNAL_EVENT 0x29060 FIXED 0x5C {; this region is used to export the software event function for quick invocation
                                                                         ; by the firmware in case of a failure
        FIRMWARE_TO_APP_RTX_SIGNAL_ROUTE.o (+RO)
  }
  ER_IROM2 +0 0X54FA0  {  ; load address = execution address
   .ANY (+RO)
  }
  RW_IRAM1 0x40000000 UNINIT {  ; RW data
  }
  RW_IRAM2_1 0x40000040 0x2000 {  ; RW data
        APPLICATION_IRAM_DUMMY.o (+RW +ZI)
  }
  RW_IRAM2_2 0x40002040 0xDFC0 {  ; RW data
        FILE_SYSTEM.o (+RW +ZI)
        .ANY (+RW +ZI)
  }
  RW_IRAM3 0x7FE00000 0x00004000  {
        LPC24_EMAC.o (+ZI +RW)
  }
  RW_XRAM1 0xA0000024 0x95FDC  {  ; RW data
        .ANY (+RW +ZI)
        APPLICATION_RAM_DISK_IMAGE.o (+RW +ZI)
        DEF_DECODE_COMMAND_DCU.o (+RW +ZI)
        DEF_DCU_FMM_MESSAGE.o (+RW +ZI)
        DEF_CHECKSUM.o (+RW +ZI)
        LCD.o (+RW +ZI)
  }
  RW_XRAM2 0xA0096000 0xC1AA04  {  ; RW data
        buffer.o (+RW +ZI)
  }
  RW_XRAM3 0xA0CB0A04 0x80C2BC  {  ; RW data
        MSCUSER_RAM_DRIVE.o (+RW +ZI)
  }
  RW_DATA_INTERFACE 0xA14BCCC0 UNINIT   {
        ; ****************************************
        ; * DO NOT MAP ANYTHING INTO THIS REGION *
        ; ****************************************
        ; DOING SO WILL BREAK THE DATA INTERFACE BETWEEN
        ; THE DCU APPLICATION AND DCU FIRMWARE
        ; SEE ABSOLUTE LOCALIZATION OF VARIABLES HERE
        ; IN 'DCU_DEF_INTERFACE.C'
  }
  RW_XROM1 0x80000000 0x80FFFFFF  {  ; NOR FLASH
  }
}

I would normally contribute, but I have a headache, and my brain is in full 'scatter' mode now.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

A much simpler version of the scatter file, auto-generated by uVision by just adding addresses from RAM and flash in the project dialogs:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x00000000 0x00001000  {    ; load region size_region
  ER_IROM1 0x00000000 0x00001000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  RW_IRAM1 0x40000000 0x00008000  {  ; RW data
   .ANY (+RW +ZI)
  }
  RW_IRAM2 0x7FE00000 0x00004000  {
   .ANY (+RW +ZI)
  }
}

LR_IROM2 0x00003000 0x0003D000  {
  ER_IROM2 0x00003000 0x0003D000  {  ; load address = execution address
   .ANY (+RO)
  }
}

This is an example for a chip that has two RAM areas. The flash has been intentionally splitted into two, just to allow some configuration data to be stored in one of the early - and small - flash sectors of the specific processor.

You can quite often get away with the auto-generated scatter file, unless your chip has very many memory areas (easy to add these sections to the scatter file) or you need to create holes or force some of the code to a specific region. The complexity of the scatter file will start to escalate when you need fancier boot-loader solutions.

well Andy, the thing that bothers me the most is the fact (as far as I could find in the documentation - somebody please do correct me if I'm wrong!) that the tool-chain has a very limited ability to integrate preprocessor stuff into a scatter file. That makes the code less maintainable due to obvious reasons.

If you need preprocessed scatter files, then I think you should write your own pre-link step.

... then, I suppose, you could feed them through the 'C' prepropcessor?

Remember: the so-called "C Preprocessor" actually knows nothing about the 'C' language or syntax - it is really just a text file processor.

I worked on a project once where the 'C' preprocessor was used to preprocess the linker scripts (althouh they weren't ARM scatter files).

I'll try to do that. thanks.

Remember: the so-called "C Preprocessor" actually knows nothing about the 'C' language or syntax - it is really just a text file processor.

Not so.

The preprocessing phases of a C compiler do know quite a but about C syntax. The preprocessor parses character and string literals, integers and float constants, and it knows enough about identifiers and operators to notice that it should macro-expand only one instance of "E2" to 2E0 in the following snippet:

#define E2 2E0
0xA0E2+1.5E2+MILE2+E2_2+E2+sizeof('E2')+strlen("E2")

That goes well beyond "just a text file processor".