# Flash Method file support. This is a template for an .ame file
# which is used along with pakflash to create Flash MEthod (.fme)
# files for RVDEBUG. This file allows use of the Settings Window to
# edit.
[TEMPLATE=FLASH/BOARD/DEVICE]
# From_flash allows separation of board details from Flash
# device details. The from_flash field points to a Flash
# device which this board uses. Care should be take to partition
# between device-specific details (such as number of blocks)
# and board/processor specific details (such as location to
# load algorithm).
from_flash=K($GROUP=FLASH/DEVICE) \\ Flash Device derived from
# The proc_name field is used to insure a match with the correct
# target processor to run the Flash algorith, It is required.
proc_name=S                     \\ name of processor (4 letter name) such as ARM
# The flash name is a more full name for the specific Flash device. It
# is used so RVDEBUG can show the exact name to the user during Flash
# programming.
flash_name=Sunnamed-flash       \\ Name of Flash device up to 31 chars.
# The width is the access size of the Flash on the bus. This is only
# important for byte addressable processors like ARM because the 
# Flash may require specific access sizes to be programmed properly.
width=V1                        \\ Width in bytes of Flash port on bus.
# The erase_value field is required when the Flash does not use ~0
# (all 1s) for its erase content (what is read in each cell after
# erasing.
erase_value=V                   \\ Value in Flash cells when erased.
# Most Flash chips are composed of multiple blocks. Each set of blocks
# with the same size and contiguous are defined using this field. So,
# this describes block-groups. The names do not matter for the block
# groups and are for your private meaning. A maximum of 8 groups may
# be specified (but any number of blocks within each group).
{block                          \\ list of block groups.
  count=V1                      \\ Number of blocks in this group
  size=V                        \\ Size in bytes of each block
  swap=B                        \\ True if must swap bytes (if width>1)
}
# The no_erase field is True when RVDEBUG does not need to pre-erase
# the Flash to program it. This is true when it auto-erases as part
# of writing or is erased electrically.
no_erase=B                      \\ True means auto-erases.
# Relocation controls are used when the algorithm is PC-relative. The
# pakflash switches can be used instead. When PC-relative, you can
# specify a start address here (for RAM or when in ROM). If you do
# not specify a start address but indicate PC-relative, RVDEBUG will 
# pick a RAM block.
{.reloc                         \\ Relocation controls
  pc_rel=B                      \\ Is PC-relative code (or can use switch).
  start_addr=V                  \\ Where to put algorith (or can use switch).
}
# When the algorithm will be in ROM (such as in a locked block of the
# Flash, the in_rom field is set to True. This way, RVDEBUG will not
# download the algorithm. The algorithm file must be the same as is
# in ROM since pakflash uses it to determine offsets to routines.
in_rom=B                        \\ Flash algorithm is in ROM already.
# The Ram group is used to define where RVDEBUG should position the
# buffer (to download what will be programmed) in RAM and any data
# needed by the algorithm. This is not needed if the buffer and/or
# data is specified in the COFF/ELF file and can be found. For ARM
# ELF files, you need to specify the symbol since the section will
# not be available.
{.ram                           \\ Details about RAM locations
  buffer=V                      \\ Where buffer is to be located
  buffer_size=V                 \\ Size of buffer in bytes
  buffer_page=K(code,data/X,IO/Y)1 \\ Page of buffer for DSPs
  buffer_sym=Sbuffer            \\ Symbol to match to find buffer
  data=V                        \\ Where Data vars are to be located.
  data_size=V                   \\ Size of data in bytes
  data_page=K(code,data/X,IO/Y)1 \\ Page of data for DSPs
}
# The symbols block is only used when the default names are not
# used. The default names are listed with each one, but are
# always FLASH_xxx where xxx is the name of the routine. Note
# that only 3 routines are required (init, write, break). Erase
# is required if the device does not auto-erase.
{.symbols                       \\ Symbol name overrides
  init=S                        \\ Instead of FLASH_init
  erase_all=S                   \\ Instead of FLASH_erase_all (optional)
  erase=S                       \\ Instead of FLASH_erase (optional)
  write_erase=S                 \\ Instead of FLASH_write_erase (optional)
  write=S                       \\ Instead of FLASH_write
  validate=S                    \\ Instead of FLASH_validate (optional)
  break=S                       \\ Instead of FLASH_break
  term=S                        \\ Instead of FLASH_term (optional)
}
# Section mapping allows specifying the names of sections for each
# part of the algorithm (code, data, buffer). The default names are
# based on the object file (".text", ".data", ".bss" for COFF), but
# this allows overriding those names. 
{.section                       \\ Section name overrides
  code=S                        \\ Code to execute.
  vars=S                        \\ Any variables and stack.
  buffer=S                      \\ Buffer to copy from.
}
# Lock_blocks allow preventing certain blocks from being modified.
# This field allows defining the HW locked blocks and creating SW
# locked blocks to stop RVDEBUG from writing/erasing them. Up to 8
# can be specified.
lock_block=LV                   \\ Blocks that are locked from change
# When the init routine or algorithm will change registers that need
# to be restored afterwards, they can be defined here. RVDEBUG will
# save their values before starting programming and will restore them
# afterwards. These can be core registers or memory mapped. The name
# of each register can be a maximum of 5 chars. Up to 8 can be specified.
restore_regs=LS
# When the init routine or algorithm will change memory that needs
# to be restored afterwards, it can be defined here. RVDEBUG will
# save the values before starting programming and will restore them
# afterwards. Only 2 ranges may be specified.
{restore_mem                    \\ memory to save/restore around programming
  base=V                        \\ Base address to save/restore
  size=V                        \\ Size of range in bytes
  page=K(code,data/X,IO/Y)1     \\ Page of memory for DSPs
}
swap_sect=S                     \\ True if SWAP BOOT section???!!!
# When RVDEBUG supports multiple APIs for Flash programming, this method
# value can be set to indicate which to use. For RVDEBUG, it is always
# left unset (or 0). When using a method DLL, this should be -1.
# Pakflash will then treat the object file as a DLL name and store
# it in the FME file for use from within RVDEBUG.
method_id=V                     \\ Programming method to use (-1 for DLL)