BootLdr and App in the same CodeWarrior Project

Started by apedroso11 February 17, 2006
Hi,

we have developed a bootloader for HC12 with CodeWarrior in C and we 
want to add it to the user application sharing the same codewarrior 
project. The aim is to force the debugger to program the app and the 
BootLdr in the flash every time you use the BDM to debug the app.

But we are facing some problems:

- We use #pragma CODE_SEG to allocate the bootloader in the 0x4000 
but the linker allocates some routines (like shifting bits), called 
from the bootldr and from the app, in user code flash space (e.g 
0xC000) since the app share the same project as the bootldr.

- After erasing the whole flash except the bootldr this routines does 
not exit anymore, so that, the bootldr crashes.

Is it the right way to program the bootldr and app together?

Will the codewarrior "link order" help us any way?

We don't want to use #pragma for every routine that the bootldr 
shares with the app to allocate it in the bootloader space because it 
will modify the app linking.

any help will be apreciated

thanks
	
Hi.

The issue might be in the erasing phase.

When you write:

"- After erasing the whole flash except the bootldr ...", are you sure
you 
do not erase also the bootloader?

We recently upgraded some of flash programmer drivers to make sure that 
when erasing range $4000-7FFF, we do not erase also the range $C000-FFFF, 
and vice versa. Indeed, page ranges are in the same flash block, and a mass 
erase on one of the ranges would automatically erase the other range (and 
more).

Also erasing the "PAGED" flash module performs a full chip mass erase,

therefore erasing both ranges here above (FLASH_4000, FLASH_C000).

Please type the 2 following commands (in CAPITAL here below) in a Command 
window:

FLASH RELEASE

FLASH
	You should get a text similar to:

FP: FLASH parameters loaded for MC9S12NE64_V11(NVMIF2) from 
D:\mars_sources\hiware\hiwave\hiwave\debug\FPP\mcu03EA.fpp
	If I am not wrong on the approach of your problem, please send me this 
info, I will try to give you more help.

Regards,
Gilles
	At 08:09 AM 2/17/2006, you wrote:
>Hi,
>
>we have developed a bootloader for HC12 with CodeWarrior in C and we
>want to add it to the user application sharing the same codewarrior
>project. The aim is to force the debugger to program the app and the
>BootLdr in the flash every time you use the BDM to debug the app.
>
>But we are facing some problems:
>
>- We use #pragma CODE_SEG to allocate the bootloader in the 0x4000
>but the linker allocates some routines (like shifting bits), called
>from the bootldr and from the app, in user code flash space (e.g
>0xC000) since the app share the same project as the bootldr.
>
>- After erasing the whole flash except the bootldr this routines does
>not exit anymore, so that, the bootldr crashes.
>
>Is it the right way to program the bootldr and app together?
>
>Will the codewarrior "link order" help us any way?
>
>We don't want to use #pragma for every routine that the bootldr
>shares with the app to allocate it in the bootloader space because it
>will modify the app linking.
>
>any help will be apreciated
>
>thanks
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
Hi apedroso11,
> >
> >Is it the right way to program the bootldr and app together?
>
>   
No. When your bootloader code and the application code are linked 
together, they will use the same runtime support functions.
The bootloader should very probably not change, just because you do 
something with the app code. For example if your app code does use an 
additional runtime routine, you do not want the bootloader's references 
to the runtime routines get updated to the new addresses.
So I really think you should have 2 projects (or at least 2 build 
targets in one project). Keep them separate.
> Will the codewarrior "link order" help
us any way?
>   
No. Your problem is that the bootloader and the app are sharing the same 
runtime support if they are in the same build target.
And with the link order, (and even with the more possible things in the 
prm file) you can tweak a bit where the runtime support code ends. But 
what I think you want are 2 instances of the runtime support.
> We don't want to use #pragma for every routine
that the bootldr 
> shares with the app to allocate it in the bootloader space because it 
> will modify the app linking.
>
> any help will be apreciated
>
> thanks
>
>   

You said your goal is to flash the boot loader always together with the 
app. I would suggest that you setup the debugger so that the debugger 
does flash both as applications together.
This is possible with the command language in the debugger, but 
honestly, that's not my area of expertise.
Basically you should have a script (in one of the *.cmd files) which 
first erases the flash, arms the flash, programs the loader, programs 
the app, and then disarms the flash.

Here's a snippet of an old email how to disable the flashing which 
currently takes place whenever you start the hiwave debugger from 
CodeWarrior:

>About your problems. The HIWAVE debugger does load
the abs file because 
>it is explicitly listed in the command line in the project settings, 
>Build Extras tab, in the Arguments box.
>Well, you don't see it here, but the macro %targetFilePath does just 
>actually expand to the abs file name. If you do not want that this 
>automatic load happens, just remove the "%targetFilePath".

Daniel
>
>
>
>  
> Yahoo! Groups Links
>
>
>
>  
>
>
>
	
Hi Gilles,

I think I haven't explain myself right. Let's try again:

- The MCU is 9S12DP256
- Our bootldr is on 0x4000. We use 16k for the bottldr (the whole page $3E)
- It doesn't use interrupts (is based on LRAE AN2546)
- The user code starts at 0xC000
- When bootldr starts, it erase Block1, Block2, Block3
   and then, the page $3C, $3D and $3F (page by page)
   We do not erase page $3E
- It works fine as a separated app from the user one. We have programmed 
several s19 files and user code always works well!

Our mates want us to integrate the bootloader with the user app in the 
same codewarrior project

After doing that, we have seen while debugging, that, after our erase 
phase (the whole flash except page $3E) some routines, which source code 
is on rtshc12.c (like _LDivMod() or _PIC_JSR_) make a CALL to 0xCE0A 
addr when the bootloader invokes them. Since we have erased page $3F 
(0xC000) these routines don't exist and the debbuger invokes a non 
implemented ISR.
It is correct because the only code is forced to be on page $3E is the 
bootloader through #pragma statements. We don't control where the linker 
allocates these intermediate routines (shifting bits, division, add, etc)

Do you think that adding the bootloader as a codewarrior subproject to 
the app project will help us building two separated apps?

In this case, how can I tell the debugger to program 2 app in flash in 
different places?

The info you requested:
-----------------
After erasing the flash except the bootloader...

in>FLASH RELEASE
in>FLASH
FP: FLASH parameters loaded for MCS912DP256B_V10 from C:\Archivos de 
programa\Metrowerks\CodeWarrior CW12_V3.1\prog\FPP\mcu03C6.fpp

MCU clock speed: 8061000 Hz
Block Module Name      Address Range   Status
   0  EEPROM               0 -   FFF   Blank - Unselected
   1  FLASH_4000        4000 -  7FFF   Programmed - Unselected
   2  FLASH_C000        C000 -  FFFF   Programmed - Unselected
   3  PAGED                  308000 -3FBFFF   Blank - Unselected
----------------

Thanks in advance
	Gilles Blanquin escribi
> Hi.
>
> The issue might be in the erasing phase.
>
> When you write:
>
> "- After erasing the whole flash except the bootldr ...", are you
sure 
> you
> do not erase also the bootloader?
>
> We recently upgraded some of flash programmer drivers to make sure that
> when erasing range $4000-7FFF, we do not erase also the range $C000-FFFF,
> and vice versa. Indeed, page ranges are in the same flash block, and a 
> mass
> erase on one of the ranges would automatically erase the other range (and
> more).
>
> Also erasing the "PAGED" flash module performs a full chip mass
erase,
> therefore erasing both ranges here above (FLASH_4000, FLASH_C000).
>
> Please type the 2 following commands (in CAPITAL here below) in a Command
> window:
>
> FLASH RELEASE
>
> FLASH
>
>
> You should get a text similar to:
>
> FP: FLASH parameters loaded for MC9S12NE64_V11(NVMIF2) from
> D:\mars_sources\hiware\hiwave\hiwave\debug\FPP\mcu03EA.fpp
>
>
> If I am not wrong on the approach of your problem, please send me this
> info, I will try to give you more help.
>
> Regards,
> Gilles
>
>
> At 08:09 AM 2/17/2006, you wrote:
> >Hi,
> >
> >we have developed a bootloader for HC12 with CodeWarrior in C and we
> >want to add it to the user application sharing the same codewarrior
> >project. The aim is to force the debugger to program the app and the
> >BootLdr in the flash every time you use the BDM to debug the app.
> >
> >But we are facing some problems:
> >
> >- We use #pragma CODE_SEG to allocate the bootloader in the 0x4000
> >but the linker allocates some routines (like shifting bits), called
> >from the bootldr and from the app, in user code flash space (e.g
> >0xC000) since the app share the same project as the bootldr.
> >
> >- After erasing the whole flash except the bootldr this routines does
> >not exit anymore, so that, the bootldr crashes.
> >
> >Is it the right way to program the bootldr and app together?
> >
> >Will the codewarrior "link order" help us any way?
> >
> >We don't want to use #pragma for every routine that the bootldr
> >shares with the app to allocate it in the bootloader space because it
> >will modify the app linking.
> >
> >any help will be apreciated
> >
> >thanks
> >
> >
> >
> >
> >
> >
> >>.
>
>
> 
>

-- 
------------
Agustin Pedroso Rizaldos
Software Engineer
R&D deparment
SEDECAL, S.A.
Tel. (+34)91 628 92 35
Fax. (+34)91 628 05 74
C/ Pelaya 9
Polono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- Espa
-----------
	
Just another hint.
When writing in C the compiler might theoretically insert a runtime 
routine for any kind of C code. In reality, it wont. It will only do it 
for operations which are not supported by the target directly, for 
example a long division. For the HC12 and if you're not using longs, 
then the most likely ones are for shifts as the HC12 instruction set 
only contains shift by one instructions. So a when not optimizing for 
speed, a runtime call is the shortest implementation for many shifts 
with higher shift amounts.

So if you're code would not contain runtime routines, then it would 
probably run just fine, right? To make runtime routines less likely, try 
to optimize for speed.
And to check if the compiler does insert any runtime runtime calls, use 
the following pragma before your code which is not allowed to use 
runtime calls.
It will cause a compile time error, so you wont be surprised at runtime.

#pragma MESSAGE ERROR C3605 /* ERROR C3605: Runtime object '_LMODS' is 
used at PC 0x21 */

Anyway, my main suggestion is still to use a separate application for 
the loader.

PS: There is also the possibility to import the code of the loader into 
the main app as SRecord in the prm file. As always, there is more than 
one way to do it.
PPS: There are also special things caller ROM library. If the boot 
loader would be a ROM library, then the main app could reuse its runtime 
support. But I would keep the two apps separate unless you really need 
to do this kind of reuse. Probably the current loader does not use too 
much of the runtime support, I would guess.

Daniel

Agustin Pedroso wrote:
> Hi Gilles,
>
> I think I haven't explain myself right. Let's try again:
>
> - The MCU is 9S12DP256
> - Our bootldr is on 0x4000. We use 16k for the bottldr (the whole page $3E)
> - It doesn't use interrupts (is based on LRAE AN2546)
> - The user code starts at 0xC000
> - When bootldr starts, it erase Block1, Block2, Block3
>    and then, the page $3C, $3D and $3F (page by page)
>    We do not erase page $3E
> - It works fine as a separated app from the user one. We have programmed 
> several s19 files and user code always works well!
>
> Our mates want us to integrate the bootloader with the user app in the 
> same codewarrior project
>
> After doing that, we have seen while debugging, that, after our erase 
> phase (the whole flash except page $3E) some routines, which source code 
> is on rtshc12.c (like _LDivMod() or _PIC_JSR_) make a CALL to 0xCE0A 
> addr when the bootloader invokes them. Since we have erased page $3F 
> (0xC000) these routines don't exist and the debbuger invokes a non 
> implemented ISR.
> It is correct because the only code is forced to be on page $3E is the 
> bootloader through #pragma statements. We don't control where the linker 
> allocates these intermediate routines (shifting bits, division, add, etc)
>
> Do you think that adding the bootloader as a codewarrior subproject to 
> the app project will help us building two separated apps?
>
> In this case, how can I tell the debugger to program 2 app in flash in 
> different places?
>
> The info you requested:
> -----------------
> After erasing the flash except the bootloader...
>
> in>FLASH RELEASE
> in>FLASH
> FP: FLASH parameters loaded for MCS912DP256B_V10 from C:\Archivos de 
> programa\Metrowerks\CodeWarrior CW12_V3.1\prog\FPP\mcu03C6.fpp
>
> MCU clock speed: 8061000 Hz
> Block Module Name      Address Range   Status
>    0  EEPROM               0 -   FFF   Blank - Unselected
>    1  FLASH_4000        4000 -  7FFF   Programmed - Unselected
>    2  FLASH_C000        C000 -  FFFF   Programmed - Unselected
>    3  PAGED                  308000 -3FBFFF   Blank - Unselected
> ----------------
>
> Thanks in advance
>
>
>
>
> Gilles Blanquin escribi
>   
>> Hi.
>>
>> The issue might be in the erasing phase.
>>
>> When you write:
>>
>> "- After erasing the whole flash except the bootldr ...", are
you sure 
>> you
>> do not erase also the bootloader?
>>
>> We recently upgraded some of flash programmer drivers to make sure that
>> when erasing range $4000-7FFF, we do not erase also the range
$C000-FFFF,
>> and vice versa. Indeed, page ranges are in the same flash block, and a 
>> mass
>> erase on one of the ranges would automatically erase the other range
(and
>> more).
>>
>> Also erasing the "PAGED" flash module performs a full chip
mass erase,
>> therefore erasing both ranges here above (FLASH_4000, FLASH_C000).
>>
>> Please type the 2 following commands (in CAPITAL here below) in a
Command
>> window:
>>
>> FLASH RELEASE
>>
>> FLASH
>>
>>
>> You should get a text similar to:
>>
>> FP: FLASH parameters loaded for MC9S12NE64_V11(NVMIF2) from
>> D:\mars_sources\hiware\hiwave\hiwave\debug\FPP\mcu03EA.fpp
>>
>>
>> If I am not wrong on the approach of your problem, please send me this
>> info, I will try to give you more help.
>>
>> Regards,
>> Gilles
>>
>>
>> At 08:09 AM 2/17/2006, you wrote:
>>     
>>> Hi,
>>>
>>> we have developed a bootloader for HC12 with CodeWarrior in C and
we
>>> want to add it to the user application sharing the same codewarrior
>>> project. The aim is to force the debugger to program the app and
the
>>> BootLdr in the flash every time you use the BDM to debug the app.
>>>
>>> But we are facing some problems:
>>>
>>> - We use #pragma CODE_SEG to allocate the bootloader in the 0x4000
>>> but the linker allocates some routines (like shifting bits), called
>>>       
>> >from the bootldr and from the app, in user code flash space (e.g
>>     
>>> 0xC000) since the app share the same project as the bootldr.
>>>
>>> - After erasing the whole flash except the bootldr this routines
does
>>> not exit anymore, so that, the bootldr crashes.
>>>
>>> Is it the right way to program the bootldr and app together?
>>>
>>> Will the codewarrior "link order" help us any way?
>>>
>>> We don't want to use #pragma for every routine that the bootldr
>>> shares with the app to allocate it in the bootloader space because
it
>>> will modify the app linking.
>>>
>>> any help will be apreciated
>>>
>>> thanks
>>>
>>>
>>>
>>>
>>>
>>>
>>> >.
>>
>>
>> 
>>
>>     
>
>
	
> - The MCU is 9S12DP256
> - Our bootldr is on 0x4000. We use 16k for the
bottldr (the whole page $3E)
> - It doesn't use interrupts (is based on LRAE AN2546)
> - The user code starts at 0xC000
> - When bootldr starts, it erase Block1, Block2, Block3
>    and then, the page $3C, $3D and $3F (page by page)
>    We do not erase page $3E
> - It works fine as a separated app from the user one. We have programmed 
> several s19 files and user code always works well!

I won't answer your question about integration with user app in CW, but some 
thoughts: your design is nowhere near the robust one. What happens when you 
erase page 3F and then there's power loss or even some glitch that forces MCU 
to reset ? If that happens on the desk, maybe there's no problem to reach for 
BDM pod, but imagine that situation when installed in the field ...

-- 
Michal Konieczny
mk@mk@....

In order to keep the bootloader and application separate, it is 
possible to manually join together the two SX/S19 files, and then 
program that into the processor.

There was a thread a few weeks ago entitled "SRecord Merge" which 
covered how to do that. You may need to turn on a linker option if it's 
not already generating SX or S19 files for the two projects.

Steve Melnikoff.

--- In 68HC12@68HC..., Daniel Friederich <dfriederich@...> 
wrote:
>
> 
> Hi apedroso11,
> > >
> > >Is it the right way to program the bootldr and app together?
	
Hi everybody,

with:

"> > >Is it the right way to program the bootldr and app
together?"

I mean through the BDM (with the debugging info).

I am trying to simplify the programing process. If I keep the bootldr 
and the app together I avoid that someone forget to program the 
bootloader after erasing the flash through BDM.

I guess the correct way to program the MCU it is to program the bootldr 
(first), to protect the flash region of the bootldr from erasing, and 
finally, to program the application (through the BDM or the bootldr.

If you want to debug an app running on the field. You have to configure 
the debugger to erase all flash except bootldr.

I'm trying to use subprojects in CodeWarrior to build the bootldr first 
and then build the app (parent project) but they seem to be projects 
thoroughly separated. And there are two debug buttons or shortcuts (one 
for each project) so I don`t find the way to debug (and program) both 
app at the same time unless the source code of both of them remain 
together in the same project.

thanks.

Steve Melnikoff escribi
> In order to keep the bootloader and application separate, it is
> possible to manually join together the two SX/S19 files, and then
> program that into the processor.
>
> There was a thread a few weeks ago entitled "SRecord Merge" which
> covered how to do that. You may need to turn on a linker option if it's
> not already generating SX or S19 files for the two projects.
>
> Steve Melnikoff.
>
> --- In 68HC12@68HC..., Daniel Friederich <dfriederich@...>
> wrote:
> >
> >
> > Hi apedroso11,
> > > >
> "> > >Is it the right way to program the bootldr and app
together?"
>
>
>
>
>
> SPONSORED LINKS
> Fast track 
>
<http://groups.yahoo.com/gads?t=ms&kt+track&w1t+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s4&.sig=nA8l9JqNmviNfMI5MX4wNQ>

> 	Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1t+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s4&.sig=R9keRDMYBnmeZHL4gCczKQ>

> 	Technical support 
>
<http://groups.yahoo.com/gads?t=ms&k=Technical+support&w1t+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s4&.sig=Sd-HtLKo96IyTEbWeB8nhw>

>
> Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1t+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s4&.sig=VAEnNl74YXlUuN2unFBtsg>

> 	Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1t+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s4&.sig=qt-XTQmiIr-YEqxb2gGstw>

>
>
>
> 
> >.
>
>
> 
>

-- 
------------
Agustin Pedroso Rizaldos
Software Engineer
R&D deparment
SEDECAL, S.A.
Tel. (+34)91 628 92 35
Fax. (+34)91 628 05 74
C/ Pelaya 9
Polono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- Espa
-----------
	
Thanks Daniel, your eMail has cleared my doubts up!

Daniel Friederich escribi
>
> Hi apedroso11,
> > >
> > >Is it the right way to program the bootldr and app together?
> >
> >  
> No. When your bootloader code and the application code are linked
> together, they will use the same runtime support functions.
> The bootloader should very probably not change, just because you do
> something with the app code. For example if your app code does use an
> additional runtime routine, you do not want the bootloader's references
> to the runtime routines get updated to the new addresses.
> So I really think you should have 2 projects (or at least 2 build
> targets in one project). Keep them separate.
> > Will the codewarrior "link order" help us any way?
> >  
> No. Your problem is that the bootloader and the app are sharing the same
> runtime support if they are in the same build target.
> And with the link order, (and even with the more possible things in the
> prm file) you can tweak a bit where the runtime support code ends. But
> what I think you want are 2 instances of the runtime support.
> > We don't want to use #pragma for every routine that the bootldr
> > shares with the app to allocate it in the bootloader space because it
> > will modify the app linking.
> >
> > any help will be apreciated
> >
> > thanks
> >
> >  
>
> You said your goal is to flash the boot loader always together with the
> app. I would suggest that you setup the debugger so that the debugger
> does flash both as applications together.
> This is possible with the command language in the debugger, but
> honestly, that's not my area of expertise.
> Basically you should have a script (in one of the *.cmd files) which
> first erases the flash, arms the flash, programs the loader, programs
> the app, and then disarms the flash.
>
> Here's a snippet of an old email how to disable the flashing which
> currently takes place whenever you start the hiwave debugger from
> CodeWarrior:
>
> >About your problems. The HIWAVE debugger does load the abs file because
> >it is explicitly listed in the command line in the project settings,
> >Build Extras tab, in the Arguments box.
> >Well, you don't see it here, but the macro %targetFilePath does just
> >actually expand to the abs file name. If you do not want that this
> >automatic load happens, just remove the "%targetFilePath".
>
> Daniel
> >
> >
> >
> > 
> > >.
>
>
> 
>

-- 
------------
Agustin Pedroso Rizaldos
Software Engineer
R&D deparment
SEDECAL, S.A.
Tel. (+34)91 628 92 35
Fax. (+34)91 628 05 74
C/ Pelaya 9
Polono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- Espa
-----------
	
Hi,
> >your design is nowhere near the robust one.
What happens when you
> erase page 3F and then there's power loss or even some glitch that 
> forces MCU
> to reset ?
Just after erasing page 3F I write the reset vector. I think it's the 
same as after a mass erase of block 3.
You always have a short period of time in which the power can go down 
and spoil your task and leave the MCU unprogrammed, without reset 
vector, and secured (by default). Haven't you?

if a more robust one is possible, please, give us a clue.

thanks.
> -- 
> Michal Konieczny
> mk@mk@....
>
>
> SPONSORED LINKS
> Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=q-PdRfkxidENbzuw47QXfA>

> 	Technical support 
>
<http://groups.yahoo.com/gads?t=ms&k=Technical+support&w1=Microcontrollers&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=nHWQ5UhrHVhjHBmJ-PV5Gg>

> 	Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=oK28VUt7GmzAuSiQ2LOclQ>

>
> Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=2wsTvt1KStqtPr3fLb1rqw>

>
>
>
> 
> >.
>
>
> 
>

-- 
------------
Agustin Pedroso Rizaldos
Software Engineer
R&D deparment
SEDECAL, S.A.
Tel. (+34)91 628 92 35
Fax. (+34)91 628 05 74
C/ Pelaya 9
Polono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- Espa
-----------