How create libraries with codewarrior

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How create libraries with codewarrior

4,592 Views
erooll
Contributor II
Hi.
I want to know how create libraries in codewarrior for HC08, HCS08 and Coldfire V1; and how use it in another projects.
My objective is distribute those libraries and not the source code.
 
Thanks
 
 
Labels (1)
0 Kudos
16 Replies

1,311 Views
erooll
Contributor II
Hi JimDon.

Well in respect about burn S19, I use to burn firmware into a final product.
Now, about create libs is in order to distribute those libs to other developers, and then they could use it in his own projects.

I'll going to do it your sugestion.

Thanks a lot JimDon.
0 Kudos

1,311 Views
CrasyCat
Specialist III
Hello
 
In order to create an object library:
  - Open your project in CodeWarrior
  - Open the Target settings dialog (Press ALT+F7)
  - In the "Target Settings" Panel,
        - set Linker to "Libmaker for HC08" if you want to create a HC08 or HCS08 library. Name of
           the generated library file must be specified in the "Libmaker for HC08" panel.
        - set Linker to "Libmaker for RS08" if you want to create a RS08 library. Name of
           the generated library file must be specified in the "Libmaker for RS08" panel.
        - set Linker to "Embedded Coldfire Linker" if you want to create a ColdFire V1 library.
          In that case you also ned to set "Project Type" to "Library in the "Coldfire Target"
          panel and adjust the File name there as well.
     
CrasyCat
0 Kudos

1,311 Views
Inebriated
Contributor I

Hi Jim,

 

What do I have to take note of with repect to the PRM file when creating libraries? Will the STACK size, RAM, Z_RAM and all other parameters declared in the PRM file of my library project affect the applications that use my library since they will most probably have different parameter values?

 

Thanks.

 

Regards,

John

0 Kudos

1,311 Views
CrasyCat
Specialist III

Hello

 

A library is only a collection of object files. As such it does not allocate any symbol to a fix address.

There is no need of a .PRM file when creating a library.

 

The symbols (function, variables, constants) defined in a library will be allocated with the application, which uses the library if they are used.

 

CrasyCat

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi CrasyCat,

 

Thanks for your reply. My question actually stems from the fact that I am developing a bootloader. I had initially integrated the bootloader and firmware application into a single project but it turned out that the bootloader had library dependencies (i.e. a switch statement actually jumps to a library) that was stored in application memory. Thus when I did a firmware upgrade, the dependcy got erased and my bootloader would crash. Therefore it turns out that i have to compile the bootloader into a library. however, there are memory allocations that have to be adhered to for the firmware application that is using it to work properly so how do i synchronise this? hmm..can I have two separate projects but they share one prm file (as you said a library doesnt require a prm file but perhaps thats the only way to "synchronise" the memory settings?) Or does a prm file have "#include" type of functionality so that it can perhaps reference an exported library .h file with the correct settings via marco definations.

 

i.e. Z_RAM =  READ_WRITE   BOOT_VAR_START TO BOOT_VAR_END;  where BOOT_VAR_START is defined to be 0x00BB and BOOT_VAR_END is defined to be 0xFF in the library .h file? 

 

Also, how do I export the library functions? Through a .h file which the exposes the function prototypes right?

 

Thanks in advance for your help.

 

Regards,

John

 

 

0 Kudos

1,311 Views
CompilerGuru
NXP Employee
NXP Employee

I would recommend to put the boot loader into its own application, not into a library.

A static library as generated by the libmaker does not work for you, it does get linked together just as your initial application. There is a special library type called ROM_LIB which could be used, but I think implementing the boot loader as its own distinct application makes most sense. Then all the interaction with the loaded application is explicit and controlled.

A boot loader and the application do need separate prm files, in the end they should not end up at the same addresses....

Create 2 prm files and provide distinct memory areas for the RAM and the FLASH. Only the stack will probably be shared.

 

 

Daniel

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi Daniel,

 

Thank you for the advice. It does indeed make sense to have 2 applications instead. However, this would complicate the programming process on the production floor. Currently we flash in the .S19 file via the PE Microlink. And this effectively erases the flash first before programming it. So if we had two different .S19 files (i.e. 2 applications as per your suggestion) they would effectively wipe each other out (since we have to program it twice). The only alternative then would be to burn in the bootloader via the PE Microlink and then burn in the application via the bootloader. But as you can see that complicates the process.

 

Can you please explain a little bit more on the ROM_Lib as that seems to be the only alternative I have right now? Thanks.

 

Regards,

John

0 Kudos

1,311 Views
CrasyCat
Specialist III

Hello

 

The linker supports a command called HEXFILE.

This command allows you to merge the content of a .s19 file to your application .abs & .s19 file.

 

This way you should be able to add your bootloader .s19 file to your application .s19 file and get one single .19 fie for programming.

 

CrasyCat

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi guys,

 

I also believe the entry points also complicate things. How do I resolve this correctly?

 

For example, upon startup, the firmware will have to know if it is to enter bootloader mode or application mode (assuming upon boot up it goes into bootloader mode which contains a routine to determine if it is to continue in boot mode or jump into application mode), which means it has to know the address to jump to. If the application and bootloader are compiled seperately then how do we get the _Startup address of the application so that the bootloader can jump to it?

 

Also, for the HEXFILE command to work properly, I suppose that I have to reduce the ROM size and range accordingly in the different prm files? (i.e. in prm file 1:application ROM address 0x8000 - 0xF5FF. prm file 2: bootloader ROM address 0xF600 - 0xFFAF) so that they will not overwrite each other?

 

Thanks.

 

Regards,

John

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi CrasyCat,

 

What care must i take in terms of the prm files? Do I have to make sure that both of them has the same parameters, at least in terms of stack address (i.e. STACKTOP) and size?

 

In your opinion, is separating them as two applications as opposed to making the bootloader a ROM_Lib the best approach?

 

Thanks.

 

Regards,

John

0 Kudos

1,311 Views
CrasyCat
Specialist III

Hello

 

According to my experience the boot loader is started first after it finishes its configuration job, it starts the application. Am I right?

 

If this is the case you just have to make sure the code (and constants) from boot loader and application do not overlap.

 

Now are you returning from application to bootloader at some point?

If yes how are you doing that? Do you have local variables or global variables inside of the bootloader that need to keep their value when you return to the bootloader?

 

CrasyCat

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi CrasyCat,

 

Yes, you are right in that the bootloader is started first and after it finishes its configuration job (mainly to determine mode of operation), it either remains in bootloader mode or starts the application.

 

For the application to jump back to bootloader mode, we trigger a reset so if you think about it the application never actually "jumps" back to the bootloader and so there is no need to take care of the local and global variables inside of the bootloader.

 

I guess the pressing question here is that, if I were to use the approach of have two applications,  how do i determine the _Startup adderess of the application so that the bootloader correctly jumps to it?

 

In the library model, the following was done:

void (* volatile const _UserEntry[])()@0xFABC={
  0x9DCC,             // asm NOP(9D), asm JMP(CC)
  _Startup
};

 

#pragma CODE_SEG Bootloader_ROM

void Bootloader_Main(void);

void _Entry(void) {
  PTGD = 0x00;   
  PTGDD = 0xF0;                   //PTG0-3 used for KBI input
 PTGPE = 0x0F;                  //Pull-up enable
 
  // MCG clock initialization, fBus=24MHz
  MCGC2 = 0x36;
  while(!(MCGSC & 0x02));        //wait for the OSC stable
  MCGC1 = 0x1B;
 MCGC3 = 0x48;
 while ((MCGSC & 0x48) != 0x48); //wait for the PLL is locked

  // Flash clock
  FCDIV=0x4E;                     // PRDIV8=1; DIV[5:0]=14, flash clock should be 150-200kHz
                                  // bus clock=24M, flash clock=fbus/8/(DIV[5:0]+1)
                                 // bus clock=24M, flash clock=fbus/8/(DIV[5:0]+1)
  if(!PTGD_PTGD0)
  {
    SOPT1 = 0x20;                   // disable COP only if bootloader mod is requested
    // PTG0 is pressed
    USBCTL0=0x44;
    Bootloader_Main();            // Bootloader mode
  }
  else
    asm JMP _UserEntry;           // Enter User mode
}

#pragma CODE_SEG default

 

Thanks,

John

0 Kudos

1,311 Views
CrasyCat
Specialist III

Hello

 

Here you need hardcoding of the address of Startup function in your bootloader.

In order to make it easier, you can get the function _Startup in a section of it sown and place that section at the beginning of a line in the PLACEMENT block.

 

This should make sure _Startup is always allocated at the beginning of a memory area.

 

If you change the start address of the memory area you need to adjust the bootloader jump address as well.

 

CrasyCat

0 Kudos

1,311 Views
Inebriated
Contributor I

Hi CrasyCat,

 

Thanks for following up on my post. I have been in touch with the guys at Freescale support and they advise that using a static library is the way to go. I have converted my bootloader into a library as a result but have not had the time to test it for cross library dependencies. I will test this as soon as I get some time to and will update this post then. maybe then we'll have clearer picture on the best approach to designing bootloaders.

 

Regards,

John

0 Kudos

1,311 Views
JimDon
Senior Contributor III
BTW You can buy a fat file system as a lib here for 499.00 with a coolboard.
899.00 with source code.
I met the guy today at FTF, and they will give full support if you find any problems.

0 Kudos

1,311 Views
JimDon
Senior Contributor III
Oh, so you make us tell you how to burn .s19 files, then you realize how that is not going to work and you decide to take my advice a do a lib.

Under target settings/linker for HCS08 there is a drop down to create a lib. If it is a CF V1 project under "Coldfire Project" you can select Project Type as Library.

As far as I know you just add a lib to your project and it will link it.

0 Kudos