rtshc08.c MC9S08GB60 bootloader in C

[ajn]

Hello!

I have seen that this issu have been discussed before.

I try to create an application in C that is able to erase the FLASH in MC9S08GB60 and reprogram it with a new version of the application.

Everything works fine: I am able to create a special SEGMENTS for the "bootloader" and I am able to erase the main() function and reprogram the same data again to restore the main() function.

But when I try to erase the functions that belongs to RTSHC08.C and MC9S08GB60.C and reprogram the same data again it fails. I can not reboot the application and start to execute it again. (Why can I not erase and reprogram these functions is it some thing special with these functions?)

So I like to move the functions in the table below to the SECTOR where the rest of the bootloader is placed.  How can I do this?

When I add the file, RTSHC08.C, to my project I get a number of error two of these are:

L1919 dublicate definition of _IDIVU_8

L1919 dublicate definition of _IMODU_8

I did not remove ansiis.lib from my project so maybe this is the problem.  Is the whole ansiis.lib based on just this file or is it a pakage of files?

My main question is how can I direct this lib or functions to correct CODE_SEG is it possible to use

#pragma CODE_SEG FAR APPL_ROM_SEG or something like this?

CrasyCat suggested earlier the following: change the link order it comes first and then adapt the content of your local rtshc08.c..

It did not help to change the link order. Instead I moved the SECTIONS:

DEFAULT_ROM, ROM_VAR, STRINGS, COPY  INTO  BOOTLOADER_ROM.

If we add new code to our project in the feture will some of the code be placed in this section by default?  I planning to suround all the application code with following pragma:

#pragma CODE_SEG FAR APPL_ROM_SEG.

will it be enough?

MODULE:                 -- RTSHC08.C.o (ansiis.lib) --
PROCEDURES:
_PUSH_ARGS_L                                182C      20      32       1   .text       
_ENTER_UNARY_L                            184C      29      41       1   .text       
_ENTER_BINARY_L_RC                    1875      19      25       1   .text       
_LCMP_k_rel_j                                    188E      1F      31       1   .text       
_LINC                                                  18AD      16      22       2   .text       
_LCMP_RC                                         18C3       6       6       2   .text       
_POP32                                              18C9      1A      26       2   .text    

Ajn 

Message Edited by ajn on 2007-04-1603:56 PM

Message Edited by ajn on 2007-04-1604:02 PM

[J2MEJediMaster]

To change the link order of files in CodeWarrior, do the following:

1) Go the the Project window and click on the Link Order tab.
2) A list of all the files used to link and build your program are displayed.
3) Click on the filenames and drag them to positions in this list that represent the link order. Files at the top are linked in first, while files further down in the list get linked after those files above them, For example, if you want rtshc08.c to be linked first, drag the file name to the very top of this window. You probably want this file to link before the ANSI library.

I'm not familiar with the HC08 tools, so I'll defer on answering about the linker command file.

---Tom

[ajn]

Thanks Tom for the fast reply.

I figure it out by my self, but it did not help to change the link order, instead I moved following sections from ROM to:

 DEFAULT_ROM, ROM_VAR, STRINGS, COPY  INTO  BOOTLOADER_ROM.

Now my question is what will happend if I add more code to my application will some of the code be placed in the BOOTLOADER_ROM sections, even if I surround it with following pragma:

#pragma CODE_SEG FAR APPL_ROM_SEG.

#pragma CODE_SEG DEFAULT

for example if I have an init const array, or something else that is not a function?

What shall I think of when I add code to my application so it not be placed in the BOOTLOADER_ROM segment that cannot be change by the bootloader?

Ajn

Message Edited by ajn on 2007-04-1604:29 PM

[CompilerGuru]

The clean solution for a bootloader setup is really to have the bootloader as its own application. This completely avoids any kind of such problems or dependencies.
I see that this is also some effort and debugging it is not that plesant. But once your loader does basically work, I would place it into its own project/build target/elffile/srecord.

In your current setup, as you place many generic sections into BOOTLOADER_ROM,

DEFAULT_ROM, ROM_VAR, STRINGS, COPY  INTO  BOOTLOADER_ROM.

it will indeed change for various reasons. For example any library functions you use are already in DEFAULT_ROM (==.text), and constants are in ROM_VAR, any string literals ("Hello World") in STRINGS, and any initialization data (int i=1 in COPY.
So the BOOTLOADER_ROM would constantly change whenever you change the application, this makes the whole bootloader idea probably pointless.

The best is, as I said, to place the loader into its own area and into its own project. This really makes the separation once and for all.

Second best would be maybe to place the runtime functions really used in your bootloader code into their own section and just link them into BOOTLOADER_ROM. Note that L1919  is a warning by default, you can even disable it if necessary.

Also, maybe (actually hopefully) it should be possible to code the bootloader so that it would not actually use runtime routines at all. There is a message which can be mapped to an error whenever the compiler wants to use a runtime routine.

The whole ANSI library consists of more than just rtshc08.c. actually rtshc08.c just contains some of the runtime routines implicitly used by the compiler, the ANSI library contains all the supported ANSI functions too (strcpy, sprintf,....).

Daniel

[ajn]

Hello Daniel,

Thanks a lot for your help. It was the runtime library, rtshc08.c, that made my program not working. I copy the rtshc08.c to my project and surround all functions in that file with #pragma CODE_SEG FAR BOOTLOADER_CODE_SEG. Then I place this file in the link tab before the ANSI library (as you have written in another thread). 
    

I also moved back the segments DEFAULT_ROM, ROM_VAR, STRINGS, COPY  to the ROM area as it is placed as default: and now am I able to eras and reprogram the FLASH. All code is now written in C and placed in only one project (the application and the "simple bootloader").

I think if you separate the bootloader and the application you will not be able to download the application via USB multilinker and start to debug it without change the s19 file. Because then you will need interrupt vector jump table which is not supported by the processor expert system? (and you cannot run the application without the bootloader either)  

If you separate the bootloader and the application you need to write the bootloader in assembler? (the only appliction notes I have seen seems to use assembler anyway) I need to download data to the bootloader via I2C and it seems to be more work to write this functionallity in assembler than in C.

>>Daniel wrote:

>>The clean solution for a bootloader setup is really to have the bootloader as its own application. This >>completely avoids any kind of such problems or dependencies.

I agree this should have been the safest way to do it, application and bootloader code will the never ever interference with each other.

Are there any pragma I can use to suppress a warnings locally in a file?

Best regards

Ake

Message Edited by ajn on 2007-04-1710:23 AM

Message Edited by ajn on 2007-04-1710:37 AM

Message Edited by ajn on 2007-04-1710:38 AM

Message Edited by ajn on 2007-04-1710:40 AM

[CompilerGuru · Accepted solution]

I think if you separate the bootloader and the application you will not be able
 to download the application via USB multilinker and start to debug it
 without change the s19 file.

I believe there is a way to configure that the bootloader is flashed before the application, and it's also not deleted while
 actually flashing it. I doubt that there is a way to have the debug information of both apps in the debugger tough.
 But I'm not the expert here.

Because then you will need interrupt vector jump table which is not supported by the processor expert system— (and you cannot run the application without the bootloader either) 

Hmm. I'm not sure if PE cannot be configured to place the vector table somewhere else. I though that this is possible,
 but I did not check (it's just not a problem I had in the past).

If you separate the bootloader and the application you need to write the bootloader in assembler– (the only appliction notes I have seen seems to use assembler anyway) I need to download data to the bootloader via I2C and it seems to be more work to write
 this functionallity in assembler than in C.

Part of the bootloader, like the vector redirection, are probably best written in assembly. Most of the bootloader like the I2C
usage can be written in C, I don't see any reason why C could not be used for that part.

 Are there any pragma I can use to suppress a warnings locally in a file˜

try

#pragma MESSAGE DISABLE C1234 /* disable C1234 because I know what I do. */


Anyway, if your setup works for you, cool :smileyhappy:
One thing to check, maybe. As you place the runtime routines into the BOOTLOADER_CODE_SEG,
their addresses becomes part of the "contract" between the boot loader and the main code.
(contract meaning that if they change, the bootloader and the app's are eventually no longer compatible)
Therefore it's probably a good idea to only really place the hopefully few runtime routines which
your loader code is using into the BOOTLOADER_CODE_SEG, and keep the rest in their usual section.
Maybe place those routines also before the other code in the loader so they do not move if the loader code changes.
Anyway, having the boot loader and the app in the same app is fragile.

Daniel

[ajn]

Thanks Daniel for all help. You have really helped me out. I will consider your good advise one more time before I decide which solution i select in this case.

Ake