[PIC] dsPIC33EP linker file understanding problem

[dhanraj.kmr]

Hi All,
I am new to dsPIC and I am trying to understand a program given by my vendor.
I am using dsPIC33EP512MU814, MPLAB X, XC16 compiler.
I have few questions from the code.
I have an application project given by my vendor which occupies primary flash memory. In order to confirm this I had to check two things. 1. Program Memory [Origin = 0x200, Length = 0x555fe] from compiler output. 2. Total auxflash memory used (bytes): 0 (0) <1%. 3. From my application configuration register, FICD register is loaded to always go to primary flash memory location after reset.

My first question is related to this. When I check the linker file(.gld), it says my program origin is 0x200, but why is __CODE_BASE is pointing to Auxiliary flash location? I tried to understand more by googling it. But all of them are program = __CODE_BASE. My linker script below(Extracted to show important portion of it),

program (xr) : ORIGIN = 0x200, LENGTH = 0x555FE
auxflash (xr) : ORIGIN = 0x7FC000, LENGTH = 0x3FF8

__CODE_BASE = 0x7FC000;
__CODE_LENGTH = 0x3FFA;

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

I assume that, at 0x7FC000 some bootloader code is there which can not be confirmed with vendor due to no contact.
So my second question is, is there any default bootloader loaded in Auxiliary flash memory by microchip?

my third question is, how the program control jumps to bootloader in after a reset issued? I know it can only goto 0x000000 location and from there GOTO instruction must point it to required location either 0x000004 or 0x7FFFFFA. but I see there is one more GOTO instruction at 0x7FFFFFC. How this is handled?
In this case, if the application is not present and only bootloader is present in Auxiliary flash memory, after power up where the control goes?

From the code, Why it is going to the Auxiliary GOTO instruction location instead of Auxiliary flash memory interrupt vector table location?

void GotoBoot(void)
{
  asm("goto 0x7FFFFC");
}

 

[FvM]

Microchip doesn't ship processors with default bootloader, it's up to you to use the auxiliary flash respectively.

For reset behavior, simply review the processor datasheet, e.g. paragraph 4.1.2 INTERRUPT AND TRAP VECTORS.

 

[Aussie Susan]

Is the .gld file from the vendor or Microchip?
If it is from the vendor then they can set things up however they like to use memory. If it is from Microchip then I must admit that I have never had to alter (or even look at) any of the provided .gld files to get any of my apps running. Mind you I've not needed to run bootstrap code in the MCUs which is about the only time that editing a .gld file is needed.
Microchip do provide documentation on the XC16 compiler (the User Guide explains a lot about memory usage and the system initialisation code the runtime library provides) and also the XC16 linker (Assembler, Linker and Utilities User Guide).
If you have the source code (you mention the XC16 compiler) then any special (code or data) memory usage should be obvious from the directives that are in the code base. By default (i.e. if you don;t specify anything) then the XC16 compiler and linker will simply generate a "working" memory layout for you.
When the device powers on or responds to a reset, the PC is set to 0x0000. The normal behaviour is for the linker to put in a GOTO command from there to wherever the initialisation code is in memory. If the code has a 'main' function then the XC16 runtime library will be the first thing called which will set up the global variables (especially if they have preset values) and then call your 'main' function. (If your main function ever returns then the XC16 runtime library code will simply reset the device and repeat the whole process again.)
Susan

 

[dhanraj.kmr]

Thanks for your replies.
My main doubt is about the conflict linker script configuration. Which is,

program (xr) : ORIGIN = 0x200, LENGTH = 0x555FE
auxflash (xr) : ORIGIN = 0x7FC000, LENGTH = 0x3FF8

__CODE_BASE = 0x7FC000;
__CODE_LENGTH = 0x3FFA;

What is the point of __CODE_BASE = Auxiliary flash memory location when the application code is sitting in Primary flash memory location? It should have been __CODE_BASE = 0x200.
Program Memory [Origin = 0x200, Length = 0x555fe]

section                    address   length (PC units)   length (bytes) (dec)
-------                    -------   -----------------   --------------------
.text                        0x200              0x2bb2          0x418b  (16779)
.const                      0x2db2               0x32e           0x4c5  (1221)
.text                       0x30e0              0x6a10          0x9f18  (40728)
.dinit                      0x9af0               0x1ee           0x2e5  (741)
.text                       0x9cde               0x9be           0xe9d  (3741)

                 Total program memory used (bytes):         0xf6ea  (63210) 12%

Even after I changed the __CODE_BASE to different value, there is no change in map file or hex file. And from the linker document, there is no information about the Base Memory Addresses - Program Memory. So I assume these label is just for information.
Thanks for your time.

 

[FvM]

What is the point of __CODE_BASE = Auxiliary flash memory location when the application code is sitting in Primary flash memory location? It should have been __CODE_BASE = 0x200.

Did you notice the configuration bit RSTPRI that can enable a reset to aux flash?

 

[dhanraj.kmr]

Hello FvM,
From my first post, Application project configuration bits window says, FICD register which contains RSTPRI is "Device will obtain reset instruction from primary flash".
So you mean my application has a reset instruction which says goto Auxiliary flash memory which is a boot memory? and __CODE_BASE value is the address reference to jump?

 

[dhanraj.kmr]

Anyway, Once I get the programmer I will have more information to understand.

 

[FvM]

So you mean my application has a reset instruction which says goto Auxiliary flash memory which is a boot memory? and __CODE_BASE value is the address reference to jump?

I mean, it can be used this way. It's the way to go to implement a fail-safe boot loader that doesn't depend on a specific content of the main flash. But I don't know how your application and boot loader design looks like.