Standalone mode & 'Banked_flash' build target

Started by christian_theiss_2003 January 29, 2003
Hi you guys at HC(S)12 yahoo group/mailing list,

...as I introduced myself yesterday a little I want to give you my
setup configuration on the hcs12 target I am working on:

* M68EVB912DP256 eval board from mot around M68Kit912DP256 bundle
* uController MC9S12DP256, revision B, mask 1k79X for this
development version on the development board
* uController MC9S12A256x for production purposes
* Metrowerk's CodeWarrior IDE, version 4.2.5.766 & full C compiler Problem description:
--------------------
* As I implemented the first hcs12 subsystem build targeting my *.abs
on the "ram" and "flash_application" to rapidly load my application
onto the on-chip flash ROM and being under the magic 64k page border
I have some more subsystems implemented and integrated and now having
around 117kB for my absolute located binary executable (*.abs) having
the need for using the "banked_flash" build target and using it.
As now is the time for going field testing I need to plug-off the BDM
multilink debug connection for driving the board in "standalone" mode
or "EVB only" mode? as motorola tells us in "MC68EVB912DP256UM/D Rev
1" user manual for this eval board. And now I have the problem often
discussed as COP watchdog timer problem in standalone mode and so I
implemented

ARMCOP = 0x55; /* reset COP in any case */
ARMCOP = 0xAA;
COPCTL = 0x00; /* disabling watchdog for isolating COP problem */

at the very beginning in init() in the start12.c startup module
generated by the hc12 stationery targets hoping to also fully working
for my hcs12 target differentiating only in a few aspects. But the
boards assumes to reset and reset again as I press the S1 hardware
reset button on eval board and I saw some valid output on the LED
bargraph on Port B in the beginning init area of my firmware code
chunk after start12.c and after main.c... and this all if plug-off
the BMD multilink connector off the eval board!!! Derived questions:
------------------
1. Do I already have a COP watchdog timer timeout problem?
2. Is it OK to choose the banked memory model with obliging the
linker to place my code firstly in the 0x4000, than 0xC000 non-paged,
than rest of the paged areas?
3. Do I have chosen the large memory model by chosing the banked
memory build target implicitely?
4. Is it not enough to set all my code with #pragma NON_BANKED hoping
not object placing my variables as 'far' ones as some of you told
some postings before?
5. Are there any clock setups concerning the CRG subsystem I have to
configure in difference to what the BDM debug ROM possibly does?
6. Do I really have to use inline assembly as told in TN120.pdf or
are the 3 C statements above OK for doing what we assume todo?

--> ...so that my system is resetting on and on? NOTE:
-----
Please note I have reviewed Metrowerk's technical note TN120.pdf
telling us some days before that all this points as reset vector,
interrupt tables in non-banked area - not paged one - and the COP
should be disabled or refreshed "early" in the startup process doing
it best in startup module - start12.c using the CodeWarrior project
trees - avoid timeout the COP watchdog. So doing all this I wonder
why I have missed something out of all this!? In the eval board spec
told above they are speaking of "Eval only" mode! Does this mean MODC
jumper couldn't be used to force BKGD pin to high or low for NORMAL
SINGLE CHIP MODE? There must be something I have really missed out,
but what I was wondering? ):

Could anyone out there give us help as we are in a blocking point
condition as we want to make our first field tests but we could not
as we really need the standalone mode!? Many thanx in advance for your appreciated help,

Christian




Hello Christian,

The COP/Watchdog is turned off by default in the HCS12 family. This was not
the case with the HC12 family. In a first time, try to make your
application run without caring about the watchdog setup. Then go back to
the watchdog handling.

If I am not wrong, the M68Kit912DP256 is delivered with the BDM Multilink
interface. The CodeWarrior for HC12 software provides a set of example
projects for the MC9S12DP256.
Please find example projects (running also in standalone) in your
installation patch subdirectories "\Examples\HC12\ICD12 Target
Interface\DP256".
-"\Fibo - Flash-Banked" is the kind of example having a banked memory
model. If you want to see something "moving" (like leds) in standalone,
merge the "Leds - EVB_DP256 - Ram" source code in the "\Fibo -
Flash-Banked" code.

The "RTKLeds - EVB_DP256 - Flash" project generates a program making leds
blinking in standalone. However, this project is not banked.

Please read also my replies inlined in your text here below.

At 07:18 PM 1/29/2003, you wrote:
>Hi you guys at HC(S)12 yahoo group/mailing list,
>
>...as I introduced myself yesterday a little I want to give you my
>setup configuration on the hcs12 target I am working on:
>
>* M68EVB912DP256 eval board from mot around M68Kit912DP256 bundle
>* uController MC9S12DP256, revision B, mask 1k79X for this
>development version on the development board
>* uController MC9S12A256x for production purposes
>* Metrowerk's CodeWarrior IDE, version 4.2.5.766 & full C compiler >Problem description:
>--------------------
>* As I implemented the first hcs12 subsystem build targeting my *.abs
>on the "ram" and "flash_application" to rapidly load my application
>onto the on-chip flash ROM and being under the magic 64k page border
>I have some more subsystems implemented and integrated and now having
>around 117kB for my absolute located binary executable (*.abs) having
>the need for using the "banked_flash" build target and using it.
>As now is the time for going field testing I need to plug-off the BDM
>multilink debug connection for driving the board in "standalone" mode
>or "EVB only" mode? as motorola tells us in "MC68EVB912DP256UM/D Rev
>1" user manual for this eval board. And now I have the problem often
>discussed as COP watchdog timer problem in standalone mode and so I
>implemented
>
> ARMCOP = 0x55; /* reset COP in any case */
> ARMCOP = 0xAA;
> COPCTL = 0x00; /* disabling watchdog for isolating COP problem */
>
>at the very beginning in init() in the start12.c startup module
>generated by the hc12 stationery targets hoping to also fully working
>for my hcs12 target differentiating only in a few aspects. But the
>boards assumes to reset and reset again as I press the S1 hardware
>reset button on eval board and I saw some valid output on the LED
>bargraph on Port B in the beginning init area of my firmware code
>chunk after start12.c and after main.c... and this all if plug-off
>the BMD multilink connector off the eval board!!! >Derived questions:
>------------------
>1. Do I already have a COP watchdog timer timeout problem?

No. Forget it in a first time, as mentioned above.

>2. Is it OK to choose the banked memory model with obliging the
>linker to place my code firstly in the 0x4000, than 0xC000 non-paged,
>than rest of the paged areas?

The "\Fibo - Flash-Banked" project is a good example. The "project.prm"
linker parameter file gives an idea about what is going to be banked and
non banked. The linker cares transparently about code spanning within the
pages.
Simply remind to store ISRs' in "non banked". >3. Do I have chosen the large memory model by chosing the banked
>memory build target implicitely?
>4. Is it not enough to set all my code with #pragma NON_BANKED hoping
>not object placing my variables as 'far' ones as some of you told
>some postings before?

The variable placement is also defined in the "project.prm" linker
parameter file. If you plan to use banked external ram in lower pages
(below page $30), please contact the support team at
<>, and mention/ask for "HCS12 banked data
with banked code with banked const" example project.

>5. Are there any clock setups concerning the CRG subsystem I have to
>configure in difference to what the BDM debug ROM possibly does?

No.

>6. Do I really have to use inline assembly as told in TN120.pdf or
>are the 3 C statements above OK for doing what we assume todo?
>
>--> ...so that my system is resetting on and on?

Make sure that your variables are declared as "volatile" when doing this.
Or a compiler might optimize this and remove the first statement "ARMCOP =
0x55;". Also remind that inlined assembler can also be affected by compiler
optimization! >NOTE:
>-----
>Please note I have reviewed Metrowerk's technical note TN120.pdf
>telling us some days before that all this points as reset vector,
>interrupt tables in non-banked area - not paged one - and the COP
>should be disabled or refreshed "early" in the startup process doing
>it best in startup module - start12.c using the CodeWarrior project
>trees - avoid timeout the COP watchdog. So doing all this I wonder
>why I have missed something out of all this!? In the eval board spec
>told above they are speaking of "Eval only" mode! Does this mean MODC
>jumper couldn't be used to force BKGD pin to high or low for NORMAL
>SINGLE CHIP MODE? There must be something I have really missed out,
>but what I was wondering? ):

No special jumper settings are required to make the board run.

>Could anyone out there give us help as we are in a blocking point
>condition as we want to make our first field tests but we could not
>as we really need the standalone mode!?

If you have a support contract, don't hesitate to contact the support team
at <>.

Regards,
Gilles >Many thanx in advance for your appreciated help,
>
>Christian >
>-------------------- >
>">http://docs.yahoo.com/info/terms/





Hello Gilles and altogether,

...thanx for your helpful explanations, Gilles! This was a lot of
help to be sure not the standalone mode was the problem but the timer
subsystem as I isolated this module off the other ones... some
configs must be done in the way they wasn't. As I use TCNT to
cyclically write a zero to it as a counter overflow occurs and as I
do this by polling I found in the subsystem spec that PLL prescaler
clock can run out of synchronization as it reads!? Perhaps a new
thread to come? I will try to fix it by tightly sticking to the
specs... Thanx for all your help,
Christian --- In , Gilles Blanquin <gblanquin@m...> wrote:
>
> Hello Christian,
>
> The COP/Watchdog is turned off by default in the HCS12 family. This
was not
> the case with the HC12 family. In a first time, try to make your
> application run without caring about the watchdog setup. Then go
back to
> the watchdog handling.
>
> If I am not wrong, the M68Kit912DP256 is delivered with the BDM
Multilink
> interface. The CodeWarrior for HC12 software provides a set of
example
> projects for the MC9S12DP256.
> Please find example projects (running also in standalone) in your
> installation patch subdirectories "\Examples\HC12\ICD12 Target
> Interface\DP256".
> -"\Fibo - Flash-Banked" is the kind of example having a banked
memory
> model. If you want to see something "moving" (like leds) in
standalone,
> merge the "Leds - EVB_DP256 - Ram" source code in the "\Fibo -
> Flash-Banked" code.
>
> The "RTKLeds - EVB_DP256 - Flash" project generates a program
making leds
> blinking in standalone. However, this project is not banked.
>
> Please read also my replies inlined in your text here below.
>
> At 07:18 PM 1/29/2003, you wrote:
> >Hi you guys at HC(S)12 yahoo group/mailing list,
> >
> >...as I introduced myself yesterday a little I want to give you my
> >setup configuration on the hcs12 target I am working on:
> >
> >* M68EVB912DP256 eval board from mot around M68Kit912DP256 bundle
> >* uController MC9S12DP256, revision B, mask 1k79X for this
> >development version on the development board
> >* uController MC9S12A256x for production purposes
> >* Metrowerk's CodeWarrior IDE, version 4.2.5.766 & full C compiler
> >
> >
> >Problem description:
> >--------------------
> >* As I implemented the first hcs12 subsystem build targeting my
*.abs
> >on the "ram" and "flash_application" to rapidly load my application
> >onto the on-chip flash ROM and being under the magic 64k page
border
> >I have some more subsystems implemented and integrated and now
having
> >around 117kB for my absolute located binary executable (*.abs)
having
> >the need for using the "banked_flash" build target and using it.
> >As now is the time for going field testing I need to plug-off the
BDM
> >multilink debug connection for driving the board in "standalone"
mode
> >or "EVB only" mode? as motorola tells us in "MC68EVB912DP256UM/D
Rev
> >1" user manual for this eval board. And now I have the problem
often
> >discussed as COP watchdog timer problem in standalone mode and so I
> >implemented
> >
> > ARMCOP = 0x55; /* reset COP in any case */
> > ARMCOP = 0xAA;
> > COPCTL = 0x00; /* disabling watchdog for isolating COP problem
*/
> >
> >at the very beginning in init() in the start12.c startup module
> >generated by the hc12 stationery targets hoping to also fully
working
> >for my hcs12 target differentiating only in a few aspects. But the
> >boards assumes to reset and reset again as I press the S1 hardware
> >reset button on eval board and I saw some valid output on the LED
> >bargraph on Port B in the beginning init area of my firmware code
> >chunk after start12.c and after main.c... and this all if plug-off
> >the BMD multilink connector off the eval board!!!
> >
> >
> >Derived questions:
> >------------------
> >1. Do I already have a COP watchdog timer timeout problem?
>
> No. Forget it in a first time, as mentioned above.
>
> >2. Is it OK to choose the banked memory model with obliging the
> >linker to place my code firstly in the 0x4000, than 0xC000 non-
paged,
> >than rest of the paged areas?
>
> The "\Fibo - Flash-Banked" project is a good example.
The "project.prm"
> linker parameter file gives an idea about what is going to be
banked and
> non banked. The linker cares transparently about code spanning
within the
> pages.
> Simply remind to store ISRs' in "non banked". > >3. Do I have chosen the large memory model by chosing the banked
> >memory build target implicitely?
> >4. Is it not enough to set all my code with #pragma NON_BANKED
hoping
> >not object placing my variables as 'far' ones as some of you told
> >some postings before?
>
> The variable placement is also defined in the "project.prm" linker
> parameter file. If you plan to use banked external ram in lower
pages
> (below page $30), please contact the support team at
> <support_europe@m...>, and mention/ask for "HCS12 banked data
> with banked code with banked const" example project.
>
> >5. Are there any clock setups concerning the CRG subsystem I have
to
> >configure in difference to what the BDM debug ROM possibly does?
>
> No.
>
> >6. Do I really have to use inline assembly as told in TN120.pdf or
> >are the 3 C statements above OK for doing what we assume todo?
> >
> >--> ...so that my system is resetting on and on?
>
> Make sure that your variables are declared as "volatile" when doing
this.
> Or a compiler might optimize this and remove the first
statement "ARMCOP =
> 0x55;". Also remind that inlined assembler can also be affected by
compiler
> optimization! > >NOTE:
> >-----
> >Please note I have reviewed Metrowerk's technical note TN120.pdf
> >telling us some days before that all this points as reset vector,
> >interrupt tables in non-banked area - not paged one - and the COP
> >should be disabled or refreshed "early" in the startup process
doing
> >it best in startup module - start12.c using the CodeWarrior project
> >trees - avoid timeout the COP watchdog. So doing all this I wonder
> >why I have missed something out of all this!? In the eval board
spec
> >told above they are speaking of "Eval only" mode! Does this mean
MODC
> >jumper couldn't be used to force BKGD pin to high or low for NORMAL
> >SINGLE CHIP MODE? There must be something I have really missed out,
> >but what I was wondering? ):
>
> No special jumper settings are required to make the board run.
>
> >Could anyone out there give us help as we are in a blocking point
> >condition as we want to make our first field tests but we could not
> >as we really need the standalone mode!?
>
> If you have a support contract, don't hesitate to contact the
support team
> at <support_europe@m...>.
>
> Regards,
> Gilles > >Many thanx in advance for your appreciated help,
> >
> >Christian
> >
> >
> >
> >--------------------
> >
> >
> >
> >">http://docs.yahoo.com/info/terms/