Split up single application into loader and application which may be replaced at run time

embeddeddavid — Fri, 05 Jul 2013 10:28:36 GMT

Setup: MC9S08JE128 + CW 10.2 + Cyclone Pro

Hello everyone,

We are currently developing an application whichs consists of loader and a application which can be replaced at runtime. We have found an interesting discussion in which it is suggested 'to split up those two separate pieces into separate elf files/build targets/applications to make 100% sure changing the application has no effect whatsoever on the loader'. In this way, each application uses its own copy of functions in ansi library (as well as propietary libraries). Additional discussions are referenced, however, we're afraid their links no longer work . There some aspects which are not discussed and we would be really grateful if someone could please give us a hand on this issue.

We think we have carefully designed the interface between loader and application in the following way:

loader uses certain functions in the app code through the application services table, which is located in a fixed ROM address (loader *.prm file guarantees this).
application uses certain functions in the loader code through the loader services table, which is located in a fixed ROM address (loader *.prm file guarantees this).
there is one single vector interrupt table: application ISRs have been redirected to a table in a fixed ROM address (loader *.prm file guarantees this) and loader ISRs are not accesible to application.
download and execution of application is managed by loader.

What we consider one of the main drawbacks here is that there is one single entry point: loader's void main (void) function. We think, moreover, this is a key difference respect having a bootloader and an application (two entry points in this case) and that is why I am using the word 'loader' instead of 'bootloader'. In this other discussion, which deals with a similar issue, it is mentioned the following: 'Just include bootloader hex or s19 file in application code using "HEXFILE bootloader.s19" command in prm file. One click and application is build and being downloaded to MCU with bootloader included.' Nevertheless, this discussion refers to the 'bootloader + app' setup case and there are some differences to take into consideration. This similar discussion is quite helpful too. There are some, let's say advantages, too: there is a single vector interrupt table and just one _Startup function (and therefore a single struct _tagStartup _startupData) and we don't have to worry about some of the points discussed.

Although we have no trouble compiling loader, compiling the application seems kind of tricky to us, as it is not an application in the strict sense of the term (it lacks of main entry point). According to what it is suggested either above as in many other discussions (Merge Bootloader + Application, bootloader and application in seperate projects, among others) we have tried to include loader.s28 file in the application by using HEXFILE command. However, it seems mandatory to implement a main dummy function. Is there any way to avoid this (i.g. by using some special 'Build Configuration') ?

In order to compile and link loader.s28 file, we add a dummy application services table, which we know will be replaced with the real one when compiling and linking application. However, we cannot think in a way to inform application compile and link processes where the loader services table is located. In fact, compiler prints out the following message: 'WARNING L1823: External object application_services_table in C:/whatever_path/application_c.obj created by default'. Does this mean we have to add the file containing loader services table to the application compilation? Is there a way to avoid this? Are we simply working in the wrong direction? (I bet the answer to this last question is YES ).

Let's suppose there is way to merge loader and application into a single *.s28 file. Is it possible to download and debug the resulting application? We are interested in debugging the application, not the loader, as we are sure the loader works fine. The following discussion talks about a similar issue. Since we are trying to download a single *.s28 file, we guess we do not have to worry about preserving any loader previously downloaded to MC9S08JE128. Are we right? Moreover, we have taken a look at the Advanced Options of the connection used in a certain Debug Configuration and it seems as if it can be preserved just three memory ranges.

Any help concerning this issue would be very much appreciated. Thanks a lot in advance.

Regards,

Re: Split up single application into loader and application which may be replaced at run time

embeddeddavid — Fri, 19 Jul 2013 19:15:16 GMT

Hi!

We were working in the wrong direction. We are currently using flash programmer to download the loader and the application segments. We are able to debug the application using the debugger.

Regards,

Re: Split up single application into loader and application which may be replaced at run time

Monica — Fri, 26 Jul 2013 00:46:17 GMT

Hello embeddeddavid!

I assumed this means your project is running now, and that is great! (Please feel free to correct me if I'm wrong)

Thanks for sharing!

Best,

Monica.

topic Split up single application into loader and application which may be replaced at run time in CodeWarrior for MCU

Split up single application into loader and application which may be replaced at run time

Re: Split up single application into loader and application which may be replaced at run time

Re: Split up single application into loader and application which may be replaced at run time