Programming two projects at once

I currently have two projects: the bootloader and the main application; both of which are loaded onto the same Microcontroller. Right now what I do is the following: load the bootloader with CodeWarrior, and then run the bootloader application and use it to program the main application using hyperterminal and the .s19 file generated by CodeWarrior.

Basically I want to reduce this two-step process into one stop, being able to program both the bootloader and application at once.

But the problem is with allocation of certain functions/constants. The Bootloader uses several ansi.c functions, which correctly loaded into the $4000-$8000 memory space where the bootloader lies (strings and constants are loaded there too). So basically EVERYTHING the bootloader needs is in this page between local address $4000 and $8000, and the code is written so that the bootloader won't allow itself to be overwritten. The application must then start at address $C000, where the bootloader jumps to.

How would I be able to compile and program the bootloader and application, but retain this rigid independence for the bootloader in the memory space I specified. The problem I foresee is that things such as STRINGS, CONSTANTS, etc. (segments from the .prm file) will then program strings and constants from the application AND bootloader into the same area, which I don't want - I need them to be totally seperate. Same issue with ansi.c functions, which both the bootloader and application use (and in the future, it could be the case that the application only gets recompiled differently, and then reference to these functions are messed up).

Anyone have any tips or suggestions on how to accomplish this in Codewarrior? The idea is to program the bootloader and application together ONCE, and then afterwards still be able to use that combined project's .s19 file to program JUST the application (now using the bootloader only).

I have thougth about the same question, and I do not have a tested solution, but I have been thinking in the direction of to somehow merge the bootloader's S19-file into the applications S19-file, either during the compile/link-process or when the debugger is started.

Is this for a HC08 or for a HC12?Either way, as the reset vector is at 0xFFFE, I'm a bit surprised that the bootloader is in the 0x4000 page. Usually the bootloader gets flashed at the end just below the vectors at 0xFFFE.Then of course you need to redirect the interrupt vectors somehow.Anyway, as changing the main app must not change the boot loader you are using the right approach to put them into separate applications (ELF files).This makes sure that both parts will have their own library functions and their own runtime support.

When you specify distinct areas in the placements of the prm files of the app and the loader, then there should be no overlapping ever. Maybe the loader reuses some of the same RAM as the app during the download, but that should not be problematic to configure.

To initially flash both the app and the loader together you have multiple paths.- as you do now, by using your own loader- include the code of the APP in the loader by referring app srecord in the loader prm (the prm command is called HEXFILE, check the Build_Tools_Utilities.pdf).- combine the two srecords and then flash the combined one. The merging can be done with the burner utility, or with any more or less smart script. Just drop the S0 and S9 frames (on the first and last line).The HIWAVE debugger supports to load srecord instead of ELF files.

- configure the HIWAVE debugger with its command line to do what you want. The automatic flashing and flash erasing can all be configured using command line commands, but I'm not the expert here.

- combine the two srecords and then flash the combined one. The merging can be done with the burner utility, or with any more or less smart script. Just drop the S0 and S9 frames (on the first and last line).

Why not simply paste the bootloader S-records (minus the S0 and S9 lines) straight into the application S19 file, using a suitable text editor.

But if you have to do it often or if you are not ever the only one which is building this app, then it a weak link in the build process.So it probably depends in which environment you work, for me, a manual copy paste would only be ok as proof of concept before this copy paste is automated somehow.

I was thinking of simply making a combined S-Record that has both the bootloader and application on it, but there are two problems with that. One, it'll be harder for someone in the future to program the application initially (I'm trying to make the inital programming procedure as simple as possible so that anyone can do it). And two, the issue with the reset vector. Right now what happens is that the Bootloader makes sure that 0x4000 is always the reset vector address (therefore starting the bootloader) - it won't allow this address to be overwritten, if a S-Record file tries to overwrite it. My application's vector table gets loaded onto the bootloader normally, except of course the reset vector, which the bootloader skips over. This works fine because the bootloader doesn't use any interrupts, and there no extra step for a jump table.

I think that the PRM file reference is the best solution - this way someone just has to program the bootloader project, and it automatically loads the application as well. I will def. try this approach!

In the end, you can try to protect the reset vector at 0xFFFE by the bootloader, but there is always a time gap when you just erased the flash and before you reprogrammed the reset vector where you could loose the control.So to my knowledge the only reliable way that the bootloader will always start, regardless of the history, is to program the bootloader at 0xC000..0xFFFF and to program the app in the rest of the flash.This does imply that all the used vectors have to be redirected by the bootloader to some secondary vector location.So something like this:

Sten, on the second bullet point, did you mean to say "an application target" instead of "a bootloader target"?

This approach works, but is just very cumbersome during development as I have to build the .S19 file with the compiler, convert that into a .hex file, and then we use Hyperterminal to load that .hex file onto the unit. So, I'll loose a fair amount of time loading and testing small changes.

Yes, the second target is the 'plain' (without included bootloader) application, intended to be downloaded with the bootloader.

In the developing phase you can download the 'procuction' target (application with included bootloader) to your hardware over the BDM if you prefer that. Then it is up to your bootloader if you have to convert the s19-file to hex and what tools to use to transmit it. My bootloader accepts s19-files directly and we have a dedicated Windows-application for the transmission (and I have found that to be faster and more conveniant than attaching the Cyclone and downloading over the BDM).