Programming two projects at once

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

Programming two projects at once

7,849 Views
MichaelA
Contributor I
Hey,
 
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).
 
Thanks,
 
Michael
Labels (1)
0 Kudos
15 Replies

1,305 Views
CompilerGuru
NXP Employee
NXP Employee
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.

Daniel
0 Kudos

1,305 Views
MichaelA
Contributor I
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!
 
Thanks for the tips!
 
- Mike
0 Kudos

1,305 Views
CompilerGuru
NXP Employee
NXP Employee
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:

BootLoaderStart:
...CheckApp...
JMP [$7FFE,PCR]; startApp.

...
ForwardFFFA:
JMP [$7FFA,PCR]
ForwardFFFC:
JMP [$7FFC,PCR]
ORG $FF..
...
; $FFFA
DC.W ForwardFFFA
; $FFFC
DC.W ForwardFFFC
; $FFFE
DC.W BootLoaderStart


(you may want to special handle the COP as well, not just the reset).

Daniel
0 Kudos

1,305 Views
ignisuti
Contributor IV

I know this is an old post, but I'm trying to combine Bootloader and App code into a single project. Has anything changed in the last few years? Is it still best to keep these as seperate projects?

 

Can anyone confirm if the PRM trick mentioned above works?

0 Kudos

1,305 Views
Sten
Contributor IV

I would recommend to keep the bootloader and application as separate projects. For the app project you can then have two different targets

  • the production target that includes the bootloader (as a 'HEXFILE path\bootcode.s19'-line in the PRM-file) to be programmed (via the BDM) into the chip during production and
  • a bootloader target (without the HEXFILE-line in the PRM-file) which generates a S19-file that can be downloaded to the chip with the bootloader

Sten

 

0 Kudos

1,305 Views
ignisuti
Contributor IV

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.

0 Kudos

1,305 Views
Sten
Contributor IV

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).

 

/Sten

 

0 Kudos

1,305 Views
ignisuti
Contributor IV

Sten, I'm slowly absorbing much of this and am beginning to understand.

 

I would like to try your suggested approach, but I do not have a PRM file (that I'm aware of). I have an LCF file. Is that the same?

 

Note: I'm using CW6.3 to develop for a MCF51CN128 chip.

0 Kudos

1,305 Views
ignisuti
Contributor IV

Also, I tried the copy/paste option for the S19 files. It seemed to work, but I got a few odd results I wasn't expecting. I'm digging into those now to try and figure out what's going on.

 

A couple of differences to note: My S-records start with S0 and S7, not S0 and S9 as mentioned in a previous post.

 

Does it matter where I copy the Bootloader's S3 records into the Application's S19 file?

0 Kudos

1,305 Views
Sten
Contributor IV

Sorry ignisuti, I do  not know how to do this for ColdFire, I've been using the approach on HCS08 (CW6.3) and HCS12 (CW5.0). Maybe someone else can help you?

 

/Sten

 

0 Kudos

1,304 Views
ignisuti
Contributor IV

No problem. I think you have me going down the right path. I just need to do a little more digging.

 

THANKS!

0 Kudos

1,304 Views
bigmac
Specialist III

Hello,


- 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.

Regards,
Mac

 

0 Kudos

1,304 Views
CompilerGuru
NXP Employee
NXP Employee
Well, copy paste works fine to get it up and running.

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.

Daniel
0 Kudos

1,304 Views
mke_et
Contributor IV
Just put conditional builds... Actually, I do it with conditional code blocks that include files.

You'll have to have a custom loader though. If you want to download a 'section', then you need an application to walk your 'S' records and selectively pull out the section you want to send.

Mike
0 Kudos

1,304 Views
Sten
Contributor IV

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.

Has anybode done something like this, and how to do it?

 

0 Kudos