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