Functions under same section

[m_embedded]

Hi all ,

i m trying to share common modules between bootloader and application code , for that i need to put function s under same section , in general the method to do this is using __attribute__

syntax
int __attribute__((section("sharedFunc"))) shared_function_1(void)
{
}

, when i m using this syntax its throwing error in ccs compiler , so experts may help me to use the correct syntax that should be used with ccs compiler to do the same ..

[Ttelmah]

It is not going to be easy.

CCS, is not at heart a linked compiler. Basically it is single pass, but does now allow external stuff to be linked to some extent.
It does not though allow relocatable 'libraries' as such.
Hence it doesn't support functions like __attribute__.
Also, by default, if a function is only used a few times, the compiler will normally 'inline' them. This is because of the very limited stack space available. When dealing with chip that only allow in some cases half a dozen calls on the stack, calling things more than is needed, can be disastrous.

What you will have to do, is create a _fixed_ 'library'. Decide on a block of memory to hold your shared functions, which is inside the bootloader range, so they won't get destroyed by the bootloader. Then declare the functions in a separate file, using #ORG to place them in this block, and using #EXPORT so their entry points are available to be used by the code. Compile these to form a .o file, then in both the bootloader and the main code, #IMPORT from this.

It is also worth understanding, that some functions _cannot_ be used this way. Things like printf for example, do _not_ compile to generic versions covering all possible values, but deliberately only include the components used be the exact calls made to them. This is done simply because the 'generic' version would be too large to fit in many PIC's. What you can do though is use this for things like maths libraries, but the number of times such libraries should be needed by a bootloader, is very limited.....

Best Wishes

[m_embedded]

If we do like this means there is chance to corrupt the bootloader code I think, though we are compiling bootloader and application with shared functions (object file), the application hex file will includes the shared modules which is in the bootloader code address range.

[RF_Developer]

Most PIC bootloaders are developed almost totally separately from the applications they will load. Most bootloaders are programmed in assembler, as its often simpler with less 'gotchas' than C, and it can fit into the limited protected bootloader areas available on most PICs.

There is therefore generally NO sharing of code whatsoever between bootloaders and bootloaded applications. There does generally need to be a sharing of processor set-up (i.e. fuses) between loaders and apps, as changing fuses during bootloading, while *possible*, is fraught with problems, often leading to "bricked" PIC due to imcompatible fuse configurations which then have to be reprogrammed from scratch.

So, any bootloader/app combo that uses shared code is almost certainly diagnostic of poor systems design. In reality, there isn't much to share: serial handler (or device for whatever means the bootloader accepts code). Bootloaders generally don't need to deal with interrupts, or at least are much simplified if they don't. So all that you really need to worry about is revectoring reset.

There are many good bootloaders available on the net (and some poor ones no doubt). Some free, other for moderate cost. Reinventing the wheel is not required. There have been many long threads on this forum about C bootloaders, which are difficult to get right, are bloated and generally a poor and expensive substitute for a decent assembler loader.

Also re-read the previous comments. CCS C doesn't have a linker and doesn't have object files. All "library code" is shared at source level, and source level ONLY.

So, maybe you might think about what your requirement really is, and get the system design right to make your job easier, rather than harder.

RF Developer.

[Ttelmah]

[m_embedded]

Thank you Ttelmah and RF_Developer, I have consider both of your valid points. Actually my bootloader is using gprs to update the code. In bootloader I have used both sms and gprs funtionalities so my code size has gone beyond the limit. So I have planned before to use shared modules, now considering RF_Developer points i have planned to do this in different way.

Though my application code is using gprs/gsm driver, I will download and store the firmware (via gprs) in EEPROM and then from bootloader I will update the code to program memory.

According to this idea, when first time firmware dump, I supposed to mix bootloader and application code in one hex file and download. Otherwise I need to give option to update firmware through bootloader in offline mode (rs232 ). Hence I don't have provision in my board for rs232, I need to go for first option.

Now my question is how to mix bootloader and application code and from one hex file ?

[Ttelmah]

Load them both into MPLAB, and export as a single file.

There are other ways, but this is about the simplest.

Best Wishes

[m_embedded]