68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

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
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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
Polígono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- España
-----------------------------------------------
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

I am being completely stupid this morning and cannot see why CodeWarrior
does not like (snippet only):
 
#define BYTE unsigned char
 
// validates and prepares an execution image. Returns the address of a
compiled execution list
BYTE *VGPreExecutive(XIMAGE x)
{
    EOBJECT *e;
    BYTE    *base;
    BYTE    *xloc;
        
    base = (BYTE *)x;
    xloc = x->obj.loc;
    xloc += base;
    e = (EOBJECT *)(base + xloc);
    return (e->loc);
}
 
It complains that the addition of the two byte pointers "xloc" and
"base" cannot be added. (ERROR C1829).  Even if I assign (BYTE *)0 to
both pointers before addition I am getting the error.
 
Please laugh at my stupidity out loud if you want, but at least tell me
how stupid I am!
 
Jonathan Masters
	[Non-text portions of this message have been removed]
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

> I am being completely stupid this morning and cannot see why CodeWarrior
> does not like (snippet only):
>  
> #define BYTE unsigned char

First of all, use this:

typedef unsigned char BYTE;

Yes, it doesn't solve anything, but this is dedicated C language construct for 
doing this.

> BYTE *VGPreExecutive(XIMAGE x)
> {
>     EOBJECT *e;
>     BYTE    *base;
>     BYTE    *xloc;
>         
>     base = (BYTE *)x;
>     xloc = x->obj.loc;
>     xloc += base;
>     e = (EOBJECT *)(base + xloc);
>     return (e->loc);
> }
>  
> It complains that the addition of the two byte pointers "xloc" and
> "base" cannot be added. (ERROR C1829).  Even if I assign (BYTE *)0 to
> both pointers before addition I am getting the error.
>  
> Please laugh at my stupidity out loud if you want, but at least tell me
> how stupid I am!

Certainly not stupid, but still some learning of C language ahead.
Two pointers cannot be added, what would you expect as result ?
You can only add numeric value (offset) to the pointer.
If you really need to add values of xloc and base, you have to cast one to 
integer value, preferably to type intptr_t, which is dedicated for such 
purpose as casting pointers to ints:
xloc += (intptr_t)base;
But double check if that's really what you want to do ...

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

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Michal Konieczny
Sent: Saturday, 18 February 2006 11:46 AM
To: 68HC12@68HC...
Subject: Re: [68HC12] Pointer hassles
 
> I am being completely stupid this morning and cannot see why
CodeWarrior
> does not like (snippet only):
>  
> #define BYTE unsigned char

First of all, use this:

typedef unsigned char BYTE;

Yes, it doesn't solve anything, but this is dedicated C language
construct for 
doing this.

> BYTE *VGPreExecutive(XIMAGE x)
> {
>     EOBJECT *e;
>     BYTE    *base;
>     BYTE    *xloc;
>         
>     base = (BYTE *)x;
>     xloc = x->obj.loc;
>     xloc += base;
>     e = (EOBJECT *)(base + xloc);
>     return (e->loc);
> }
>  
> It complains that the addition of the two byte pointers "xloc" and
> "base" cannot be added. (ERROR C1829).  Even if I assign (BYTE *)0 to
> both pointers before addition I am getting the error.
>  
> Please laugh at my stupidity out loud if you want, but at least tell
me
> how stupid I am!

Certainly not stupid, but still some learning of C language ahead.
Two pointers cannot be added, what would you expect as result ?
You can only add numeric value (offset) to the pointer.
If you really need to add values of xloc and base, you have to cast one
to 
integer value, preferably to type intptr_t, which is dedicated for such 
purpose as casting pointers to ints:
xloc += (intptr_t)base;
But double check if that's really what you want to do ...

-- 
Michal Konieczny
mk@mk@....
	Michal,
Thankyou. I am old enough and ugly enough to know I can't meaningfully
add pointers. I don't know what I was trying to do. I had solved the
problem a moment ago by casting, but your point about (intptr_t) is new
to me and I will make adjustments.
Jonathan.
SPONSORED LINKS 

Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontroller
s&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers&
c=4&s=98&.sig=q-PdRfkxidENbzuw47QXfA>  
Technical
<http://groups.yahoo.com/gads?t=ms&k=Technical+support&w1=Microcontrolle
rs&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrollers
&c=4&s=98&.sig=nHWQ5UhrHVhjHBmJ-PV5Gg>  support 
Intel
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontr
ollers&w2=Technical+support&w3=Intel+microprocessors&w4=Pic+microcontrol
lers&c=4&s=98&.sig=oK28VUt7GmzAuSiQ2LOclQ>  microprocessors 

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

>  Terms of Service. 
 
  _____
	[Non-text portions of this message have been removed]
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

 > Thankyou. I am old enough and ugly enough to know I can't meaningfully
 > add pointers. I don't know what I was trying to do. I had solved the
 > problem a moment ago by casting, but your point about (intptr_t) is new
 > to me and I will make adjustments.

intptr_t is introduced in stdint.h, which is part of C99, but many compilers 
have it event if not implementing full C99.

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

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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?
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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&k=Fast+track&w1=Fast+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s=114&.sig=nA8l9JqNmviNfMI5MX4wNQ>

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

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

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

> 	Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Fast+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s=114&.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
Polígono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- España
-----------------------------------------------
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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
Polígono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- España
-----------------------------------------------
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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=98&.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=98&.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=98&.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=98&.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
Polígono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- España
-----------------------------------------------
	

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

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

- first of all, you put the bootloader in page 3F, using top of the 
FLASH, covering security byte, protection byte and the whole vector 
table. How much memory you use, it depends on the size of your 
bootloader, maybe 2k, maybe 4k, 8k or 16kB, it doesn't matter. Just top 
of the page 3F.
- you program protection byte to the value that covers size and location 
of your bootloader, so whole bootloader (and vector table of course) is 
erase- and write-protected
- you probably also set security byte for disabling read-out of memory 
contents, but it doesn't really matter here
- in your bootloader, there's jump table and redirection procedure for 
all interrupt vectors, that redirects them to the real user code, 
outside of bootloader; it requires "shadow" vector table in user code; 
redirection procedure verifies if given vector in user code "shadow" 
vector table is valid, and jumps there, or treats the interrupt as spurious
- user code must have some kind of signature and control sum, that 
enables the bootloader to check for it's validity - on startup, 
bootloader validates user code in flash, if valid then it is executed, 
if not, bootloader waits for user code upload.

This way, you NEVER erase reset vectors, and regardless of what happens, 
you always get the bootloader started out of reset. No need for BDM pod, 
whatever happens during upload.

There's still one possible problem - if the bootloader erases user code 
area in flash, and upload procedure is aborted, you are left with the 
bare bootloader only and no user code. You still have device 
operational, now you can retry upload procedure and restore device 
operation, but there's risk leaving the device with no user code, when 
there's trouble with upload, especially when the connection is over 
unreliable network.
I have such a case, and my solution is as follows: the device is NE64, 
and it has additional external serial I2C EEPROM 64kB (24LC512). User 
code upload doesn't erase internal NE64 FLASH, only writes the uploaded 
code to external EEPROM. Upload procedure is executed during normal 
device operation (in the "background"), so the normal operation isn't 
stopped nor interrupted (the bootloader isn't entered) - it's done 
simultaneously with the main task (upload procedure is available from 
two places - from bootloader, when the device has no user code, and from 
user code). When upload is finished, signatures and checksums are 
validated (in external EEPROM). If invalid code is uploaded, it's just 
ignored and device continues previous job. If valid code is detected, 
MCU reset is ordered. After reset, bootloader is entered, and it 
validates the code in external EEPROM. If it isn't valid, previous code 
from MCU FLASH is run (it wasn't erased yet), and the device restores 
normal operation. If new code in external EEPROM is valid, then MCU 
FLASH is erased and programmed with data taken from external EEPROM. 
After this, MCU FLASH is validated (write verify operation). If valid, 
then erase external EEPROM data (not whole, just signature), so during 
next MCU reset it isn't rewritten into MCU FLASH. From now on, device 
runs new code. If FLASH write error happens, there are few retries, if 
they fail, bootloader signals fatal hardware error.

This way, I protect the device against being left with no user code when 
upload procedure is interrupted, or invalid data is uploaded. The only 
way to break it is to load invalid firmware with valid signatures and 
control sums, but that's just sabotage, not run-time problem. No 
transmission trouble (interruption, errors) can leave device in 
no-operational state. Downtime for firmware upload is also minimized to 
time required to reset MCU, verify EEPROM data and rewrite it into 
FLASH, firmware upload procedure is handled "in the background" during 
normal operation.

That's my way for reliable devices.

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

(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hi,

I put bootloader in page 3E.

I'll continue reading yor email

Thanks for answering!

Michal Konieczny escribió:
> >>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.
>
> - first of all, you put the bootloader in page 3F, using top of the
> FLASH, covering security byte, protection byte and the whole vector
> table. How much memory you use, it depends on the size of your
> bootloader, maybe 2k, maybe 4k, 8k or 16kB, it doesn't matter. Just top
> of the page 3F.
> - you program protection byte to the value that covers size and location
> of your bootloader, so whole bootloader (and vector table of course) is
> erase- and write-protected
> - you probably also set security byte for disabling read-out of memory
> contents, but it doesn't really matter here
> - in your bootloader, there's jump table and redirection procedure for
> all interrupt vectors, that redirects them to the real user code,
> outside of bootloader; it requires "shadow" vector table in user code;
> redirection procedure verifies if given vector in user code "shadow"
> vector table is valid, and jumps there, or treats the interrupt as 
> spurious
> - user code must have some kind of signature and control sum, that
> enables the bootloader to check for it's validity - on startup,
> bootloader validates user code in flash, if valid then it is executed,
> if not, bootloader waits for user code upload.
>
> This way, you NEVER erase reset vectors, and regardless of what happens,
> you always get the bootloader started out of reset. No need for BDM pod,
> whatever happens during upload.
>
> There's still one possible problem - if the bootloader erases user code
> area in flash, and upload procedure is aborted, you are left with the
> bare bootloader only and no user code. You still have device
> operational, now you can retry upload procedure and restore device
> operation, but there's risk leaving the device with no user code, when
> there's trouble with upload, especially when the connection is over
> unreliable network.
> I have such a case, and my solution is as follows: the device is NE64,
> and it has additional external serial I2C EEPROM 64kB (24LC512). User
> code upload doesn't erase internal NE64 FLASH, only writes the uploaded
> code to external EEPROM. Upload procedure is executed during normal
> device operation (in the "background"), so the normal operation isn't
> stopped nor interrupted (the bootloader isn't entered) - it's done
> simultaneously with the main task (upload procedure is available from
> two places - from bootloader, when the device has no user code, and from
> user code). When upload is finished, signatures and checksums are
> validated (in external EEPROM). If invalid code is uploaded, it's just
> ignored and device continues previous job. If valid code is detected,
> MCU reset is ordered. After reset, bootloader is entered, and it
> validates the code in external EEPROM. If it isn't valid, previous code
> from MCU FLASH is run (it wasn't erased yet), and the device restores
> normal operation. If new code in external EEPROM is valid, then MCU
> FLASH is erased and programmed with data taken from external EEPROM.
> After this, MCU FLASH is validated (write verify operation). If valid,
> then erase external EEPROM data (not whole, just signature), so during
> next MCU reset it isn't rewritten into MCU FLASH. From now on, device
> runs new code. If FLASH write error happens, there are few retries, if
> they fail, bootloader signals fatal hardware error.
>
> This way, I protect the device against being left with no user code when
> upload procedure is interrupted, or invalid data is uploaded. The only
> way to break it is to load invalid firmware with valid signatures and
> control sums, but that's just sabotage, not run-time problem. No
> transmission trouble (interruption, errors) can leave device in
> no-operational state. Downtime for firmware upload is also minimized to
> time required to reset MCU, verify EEPROM data and rewrite it into
> FLASH, firmware upload procedure is handled "in the background" during
> normal operation.
>
> That's my way for reliable devices.
>
> -- 
> Michal Konieczny
> mk@mk@....
>
>
> SPONSORED LINKS
> Fast track 
>
<http://groups.yahoo.com/gads?t=ms&k=Fast+track&w1=Fast+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s=114&.sig=nA8l9JqNmviNfMI5MX4wNQ>

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

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

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

> 	Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Fast+track&w2=Microcontrollers&w3=Technical+support&w4=Intel+microprocessors&w5=Pic+microcontrollers&c=5&s=114&.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
Polígono Ind. "Rio de Janeiro"
28110 Algete (Madrid)- España
-----------------------------------------------
	

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )