v3.20

Assembler

• New section attributes for creating heap or stack allocations in source code. For example:

    .section mystack,stack
    .space 512
  
    .section myheap,heap
    .space 256
  

  The stack attribute defines a section type, and is compatible with attribute modifiers address() and align().

  The heap attribute defines a section type, and is compatible with attribute modifiers address(), xmemory, ymemory, and align().

• New section attribute eds for allocating memory in extended data space on some future devices. The eds attribute modifies sections of type bss, data, and persist.

• New section attribute page to indicate that a section must not cross a natural page boundary. It ensures that a single setting of the page register is sufficient to access the entire section. The page attribute modifies sections of type bss, data, persist, code, psv, and eedata. In the case of psv, the page attribute is redundant, since by definition sections of type psv avoid page boundaries.

• New operator edspage() can be applied to symbols in data memory or program memory. It returns the page value that can be used to make the object visible in the extended data space window. edspage() always returns a 10-bit result.

• New operator edsoffset() can be applied to symbols in data memory or program memory. It returns a 16-bit offset that can be used in combination with an object's page value. For objects located in the first 32K of data memory, edsoffset() returns the object's true address. For all other objects, it returns an address in the PSV or extended data space window.

• Feature preprocessor definitions which can be used to identify special properties of the different 16-bit devices. Definitions such as __HAS_DSP can be tested by assembler preprocessor directives. A complete list of definitions may be found in chapter 5.9, "Predefined Symbols", in the Assembler manual.

Linker

• The linker allocates variables in space(eds) on any page where memory is available. However, the linker will use extended RAM first, in order to preserve memory for the stack.

• New linker script commands specify startup files. On some future devices PSVPAG is no longer used to access constants stored in program memory. On such devices the standard startup files can not be used. In order to support multiple startup files, new commands specify files appropriate for the target device. For example:

    CRT0_STARTUP(crt0_standard.o)
    CRT1_STARTUP(crt1_standard.o)
  

  These commands replace the EXTERN() commands which previously appeared near the top of linker scripts. See Migration Issues for more information.

• Linker scripts are now pre-processed using the standard C pre-processor. Macros can be defined in the Build Options dialog of MPLAB IDE.

• To accomodate future devices with extended data memory, the data initialization template has been modified to encode page numbers. For more information, see chapter 10.8, "Initialized Data", in the Linker manual.

• Object files now contain signatures for the purpose of matching objects created with different compiler options. In the current release, objects loaded from libraries are selected to ensure consistent setting of the -mlarge-arrays option. Two new linker options have been added to control this feature:

    --select-objects     Select library objects based on options (default)
    --no-select-objects  Don't select library objects based on options
  

v3.12

Linker

• The memory usage report (which appears in the map file as well as console output) has changed in two ways. First, sections marked noload will now appear in the report, and will count towards the total memory used. In the unusual case where two noload sections have been declared at the same address, the total memory value will be distorted.

  Second, the Program Memory report will only show sections actually defined in memory region "program". Previously, the reset vector and interrupt vector tables were included in this section of the report. However, these sections are defined in separate memory regions, and their appearance in the report can be confusing since these sections are not really part of the application code, which is otherwise variable in size.

  To clarify the second change, headings in the usage report now include the origin and length as defined in the linker script. For example:

    Program Memory  [Origin = 0x100, Length = 0x3ff00] 
  
    section                    address   length (PC units)   length (bytes) (dec) 
    -------                    -------   -----------------   -------------------- 
    .text                        0x100               0x56e           0x825  (2085) 
    .const                       0x66e                 0x6             0x9  (9) 
    .dinit                       0x674                0x82            0xc3  (195) 
    .text                        0x6f6                 0xa             0xf  (15) 
    .isr                         0x700                 0x2             0x3  (3) 
  
                         Total program memory used (bytes):          0x903  (2307) <1% 
  

Disassembler

• The disassembly listing generated by pic30-objdump has been improved. Instead of representing the target address of branch and DO instructions as a PC-relative offset (using a "dot expression"), the absolute target address will be displayed. If a label at the target address can be identified, it will be displayed also. For example, a previous listing:

    f8 ff 3a        bra       NZ, . + 0xFFFFFFF2
    b8 ff 07        rcall     . + 0xFFFFFF72
  

  is now displayed as:

    f8 ff 3a        bra       NZ, 0x4F4 <.L26>
    b8 ff 07        rcall     0x46C <_fclose>
  

v3.11

The default stack guard band has been increased from 8 to 16 bytes, to adequately handle stack overflow exceptions that may occur from certain instruction sequences. The size of the guard band can also be specified with a new linker option. See Migration Issues for details.

v3.10 (C) Support Update

This support update to version 3.10 includes updates to the following device files:
dsPIC33FJ06GS101, dsPIC33FJ06GS102, dsPIC33FJ06GS202, dsPIC33FJ16GS402, dsPIC33FJ16GS404, dsPIC33FJ16GS502, and dsPIC33FJ16GS504

See Fixed Issues for additional updates.

v3.10

This version includes support for 5 new devices: PIC24F04KA201, PIC24F08KA101, PIC24F08KA102, PIC24F16KA101, and PIC24F16KA102.

See Migration Issues for information about how existing projects may be affected.

Assembler

• A new directive .memory can be used to define external memory regions. Sections may be assigned to memory regions by using the memory section attribute. See chapter 6 of MPLAB Assembler, Linker and Utilities for PIC24 MCUs and dsPIC DSCs User's Guide for details.

Linker

• Several improvements to the linker memory allocator, especially with regards to absolute sections and psv sections. For example, absolute sections may be defined in source code to reside at any address. The sequential memory allocator will avoid absolute sections, if necessary.
• The linker allocates external memory regions as defined in C or assembly language. Each memory region includes a unique address space into which sections may be allocated. See chapter 10 of MPLAB Assembler, Linker and Utilities for PIC24 MCUs and dsPIC DSCs User's Guide for details.
• The definition of output section .text in linker scripts includes a new input section named .user_init. This section is used by the compiler to generate activation code for user_init sections. The expression *(.text) has been removed, allowing application code to flow around psv sections as necessary, instead of always being allocated in a single large block. The new definition is:

    .text :
    {
          *(.init);
          *(.user_init);
          *(.handle);
          *(.libc) *(.libm) *(.libdsp);  /* keep together in this order */
          *(.lib*);
    } >program
  

• The linker script command language supports a new command OPTIONAL which is analogous to INPUT, except that no error occurs if the input file or library can not be found. An exact input file may be specified, or an abbreviated library file name with the -l prefix.

Migrating to Version 3.20

Linker scripts provided with v3.20 include new commands to specify start-up files for the target device. If these commands are not found, the linker will select default versions. Existing projects with custom linker scripts will function correctly for all current devices. However, the following warning messages may be displayed:

  Warning: linker script did not specify CRT0_STARTUP file, default for this device: crt0_standard.o 
  Warning: linker script did not specify CRT1_STARTUP file, default for this device: crt1_standard.o 

To quiet these warnings, replace the two EXTERN() commands near the top of the linker script with:

  CRT0_STARTUP(crt0_standard.o)
  CRT1_STARTUP(crt1_standard.o)

The tblpage() operator now returns a value with bit 8 set, even though the TBLPAG register implements bits 0-7 only. The extra bit allows for better code generation by the compiler. Existing projects should not be affected by this change, unless an assembly source file uses the tblpage() operator with a mov.b instruction. In that case, a "relocation truncated to fit" error may be reported. To resolve this problem, revise the assembly source to use a word sized instruction.

When the psvpage() operator is used with future devices that support extended data memory, a 10-bit value is returned. Assembly source files that use the psvpage() operator with a mov.b instruction should be modified to use a word sized instruction.

The C-runtime startup has been enhanced to support data initialization outside of the standard 32K data memory range. There are no migration issues for customers using devices released with prior versions of the tool chain. However, if you have included customized versions of the startup files you may wish to apply those enhancements for future devices. For more information, look in files crt0_standard.s and crt0_extended.s, which are contained within the libpic30 archive.

Because of changes to the startup file architecture, it is no longer possible to load a library startup module by calling __reset. If a custom startup file needs to invoke the standard startup file, copy crt0_standard.s to the project.

Migrating to Version 3.12

No significant migration issues have been identified. However, the format of link map files and disassembly listings has changed slightly (see What's New for details.) Custom tools or scripts which post-process such files may need modifications to accomodate these changes.

Migrating to Version 3.11

The default stack guard band has been increased from 8 to 16 bytes. This results in a corresponding decrease of usable stack space available to applications. To faciltiate the recovery of lost stack space, or to specify a larger guard band for non-trivial exception handlers, a new linker option has been added. For example, to restore stack allocation to match previous versions:

     --stackguard=8

Migrating to Version 3.10

• Installation Directory has been Re-organized

  MPLAB IDE will report "File not found" for support files referenced by projects in the old locations. MPLAB IDE v8.10 or later provides an easy way to resolve such problems. Simply right-click on the missing project files and select "Locate Missing File" or "Remove". In most cases MPLAB IDE will locate the missing project file automatically. If the missing file is a standard linker script, then removing the file will suffice, since standard linker scripts are included automatically in MPLAB IDE v8.0 or later. If the missing file is a device-specific library, then removing the file will also suffice, since standard linker scripts now include peripheral libraries automatically.

  The bin folder has also changed. Tools that are specific to the object file format have been moved to a lower level. This change should not impact existing projects, since these tools should always be invoked by the generic versions which are located in the standard location.

• Memory Map has been Simplified

  The linker's best-fit allocator will merge output sections with the same name whenever it is convenient to do so. This will change the memory usage report and link map. For example, several adjacent sections named .bss will now be merged into one.

  Section .text will flow around section .const (or other psv sections) as necessary. To facilitate this new behaviour, the expression *(.text) has been removed from the definition of output section .text in linker scripts. This may change the organization of sections in program memory, since .text will now be allocated in multiple chunks if necessary. Existing projects which depend on a single .text section can revert to the previous behaviour by restoring the definition of output section .text.

None.