|
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 |
|
|
Standalone mode & 'Banked_flash' build target
Started by ●January 29, 2003
Reply by ●January 30, 20032003-01-30
|
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/ |
|
|
Reply by ●February 3, 20032003-02-03
|
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/ |
