9S08QG8 external oscillator problem

[tonyp]

Hello,

Using a 32.768KHz crystal with a 9S08QG8, I can't get it started unless I turn on ERCLKEN. This one bit in Freescale's examples is off for FEE, and I find that without it being on, there is no oscillation. ERCLKEN is supposed to be used only for providing a source for RTI, nothing else, AFAIU.

Is this a bug, a manual/reference error, or what? I've looked at these:
HCS08QRUG Rev 1, p. 16
MC9S08QG8 Rev 1.01, p. 149, section 10.4.1.2 (FEE)

which imply ERCLKEN is irrelevant for starting FEE.

The MCU is M9S08QG8, CPBE 3M77B, RMAA0545

Thanks.

[tonyp]

Can someone from Freescale please verify the above behavior as either true or false?  The code to test is this (where, if ERCLKEN is off, oscillator does not start even though EREFS is on):

         mov       #%00000110,ICSC2
                   ; |||||||+--------- EREFSTEN
                   ; ||||||+---------- ERCLKEN (change to 0 and see if it oscillates)
                   ; |||||+----------- EREFS
                   ; ||||+------------ LP
                   ; |||+------------- HGO
                   ; ||+-------------- RANGE
                   ; ++--------------- BDIV

         brclr     OSCINIT.,ICSSC,*

         clr       ICSC1

If indeed there is a problem, you won't get past the BRCLR instruction (and the oscillator will not work).

I also have another strange behavior with the RTI on the same chip.  It won't accept the external reference as a source clock (i.e., no interrupts), it only works with the internal 1KHz reference.  No stop modes are involved, so the EREFSTEN bit shouldn't matter. Again, can someone verify this? This is the code (where, if RTCLKS is 1 [external], no interrupts are triggered):

         lda       #%00010001
                     |||||+++--------- RTIS - Period for RTI
                     ||||+------------ Reserved
                     |||+------------- RTIE - Interrupt Enable
                     ||+-------------- RTCLKS - RTI Clock Source (change to 1 and see)
                     |+--------------- RTIACK - Interrupt Acknowledge
                     +---------------- RTIF - Interrupt Flag
         sta       SRTISC              ;turn on RTI interrupts

         ...

RTI_Handler
         lda       #RTIACK_
         ora       SRTISC
         sta       SRTISC              ;reset the interrupt
         rti

        org       Vrti

        dw        RTI_Handler

If RTCLKS is 1, the RTI_Handler isn't entered.

The code as is works with external 32.768KHz crystal and internal RTI 1KHz reference.

Thanks.

P.S. To whoever rated my original post as average, it'd be nice if they also bothered to tell the world how come, while they obviously can't offer any advice (even a simple one, like: it's in the book, read p. xxx), they feel they're justified to rate something for which they have nothing to say.  Plain arrogance, I guess.  If they at least offered some useful advice, I'd be happier with even a zero rating from them!

[glork]

Hi Tony from Ron.
I don't see where anyone else has offered up any help, and I'm interested because I'm considering using this chip.
I've checked the manual and p.149 lists the things required to operate FEE; it specifically does not include any requirement for erclken.

You may have to submitt a SR to get any attention.  At any rate I hope to see a definitive answer on this.

PS: don't worry about the ratings -- if your question had involved some nitwit "C" problem or something about processor expert I'm sure it would have been viewed favorably.

[tonyp]

Issued resolved by SR to Freescale.

1. ERCLKEN *has* to be on (along with EREFS) for crystal to work.

2. The RTI not working when ERCLKEN is on happens only in BDM.  In stand-alone mode it works as expected.  (So, I guess, one has to use the unstable internal 1KHz clock for debugging, and switch to the external one for real use.)

Thank you all.

[peg]

Hi Tony,

Guess I'm a little late now, but I can confirm point 1 in your last post by experimentation.

Did not get to the second one.

I don't suppose you got an answer to your original question as to whether this is a bug or a often repeated documentation error???

BTW, I too was baffled by the original rating of your first post in this thread.

To me now this thread now warrants the highest possible rating as it has essential information that is not available anywhere else.

Message Edited by peg on 2007-04-0310:54 PM

[Alban]

Hello Tonyp,

If you require an answer from Freescale, you must enter a Service Request.

Click here to Submit a new Service Request now

Answers made by people here are never in Freescale name, except when:

- clearly identified as such,

- include a source (department, name, role)

- posted by a member with Freescaler, Moderator, or Administrator status.

All three conditions must be fulfilled to qualify.

To all Freescalers, Moderators and Administrators,
Freescale SOP striclty forbids you to speak in the name of the Company unless your text has been approved by the Legal Department as beeing checked truthful and in wording not leaving any place to mis-interpretation. This is the same in any Company, not a Freescale special restriction.

About the post scriptum. Rating is up to the person who rate and retaliation will only mean a bad (by opposition to average) rating because of bad spirit.

Posts can be qualified as average, for instance, when the level of details of research made before requesting help was not enough for the person to reply.

Average means average and does not mean bad. An excellent post is better than average because of its content which the reader will have found particularly interesting or of great general help.

A question requiring a "read the book" answer is rather bad than average as reading the manual is the first thing a user should do generally speaking and not only on Freescale products.

Finally, average ratings is what allows user to get a valid Trusted Contributor status. A Trusted Contributor with only "one" rating is quite subjective. A Trusted Contributor with 256 ratings will certainly have average in his/hers, but is more widely recognized.

Alban.