Exact match. Not showing close matches.
'[PIC] 18F secondary oscillator'
|On 5 June 2012 02:16, Neil <narwani.org> wrote: picdude3
> My guess (just a guess) is that because of some other interrupt being
> serviced when the TMR1H interrupt occurs, TMR1L may be about to overflow
> and update TMR1H when the code is updating it too, resulting in some
> type of "conflict". I say "conflict" as if it were just that the
> overflow and subsequent TMR1H increment occurs before the code changing
> TMR1H, then a bit of time would be lost.
> To test my assumption, I'm thinking I could probably wait in a loop
> (ugh! -- I hate that in interrupts) until TMR1L is some low value, and
> then re-load TMR1H. I'd also have to check for TMR1H already being
> incremented (by a TMR1L overflow), and compensate for that. I vaguely
> remember some discussion of this for older 16F chips, but not coming up
> with much right now. Will search better when I have a better internet
18F chips have a dual-priority interrupt system. Try using that before
doing loops, etc. Set you're overflow ISR as high priority and
everything else as 'standard' priority. (Also, the high priority ISR
automatically saves context on interrupt entry and exit IIRC). Low
priority ISRs can be interrupted by high priority ISRs but not the
other way around.
All the best
-- Brendan Gillatt
I have priorities in use, with 1 timer as low priority and 3 timers as high. The multiplexed display updates are usually high as I get a slight flicker on the display otherwise, but now that I'm running at 32Mhz, I've set it to low priority and it seems to be fine. I'm retesting the clock now, but if that issue is still not resolved, I have one other option...
Other than the 32.768khz osc, the only other high-priority timer now is the one that samples a bit for a frequency measurement. That code is relatively bulky (for an ISR), so I suspect it will have to change somehow. I'm thinking I'll need to come up with some way to sample the bit at the correct time and store it. Either store in a queue for later processing in main code, or store a single bit sample and force trigger a low-priority interrupt for relatively immediate processing. For the latter, I'm guessing I can just force on the interrupt flag for some interrupt I'm not using (another timer, etc).
Curious -- if some high-priority interrupt code is being processed and before it completes 2 low-priority interrupts are triggered, is there a defined order in which those get processed when the high-priority interrupt completes? I suspect the PIC looks for these in some hard-coded order, or perhaps it would know which got triggered first, but I've not seen anything in the datasheet that indicates that either of these is true.
On 6/5/2012 3:44 PM, Brendan Gillatt wrote:
> 18F chips have a dual-priority interrupt system. Try using that before
> doing loops, etc. Set you're overflow ISR as high priority and
> everything else as 'standard' priority. (Also, the high priority ISR
> automatically saves context on interrupt entry and exit IIRC). Low
> priority ISRs can be interrupted by high priority ISRs but not the
> other way around. All the best
It gets worse -- I put all 3 other timers as low-priority, so the 32.768khz osc is the only remaining high-priority interrupt, and time is still moving fast. Now I'm lost... and desperate to figure this out.
On 6/7/2012 2:20 PM, Neil wrote:
>> other way around. All the best
Neil wrote 2012-06-07 21:04:
>> Curious -- if some high-priority interrupt code is being processed and
>> before it completes 2 low-priority interrupts are triggered, is there a
>> defined order in which those get processed when the high-priority
>> interrupt completes? I suspect the PIC looks for these in some
>> hard-coded order, or perhaps it would know which got triggered first,
>> but I've not seen anything in the datasheet that indicates that either
>> of these is true.
No, the PIC does not keep track on in which order the different
*IF flags are set. As soon as the ISR can be called, one or many
IF-flags *could* have been set. The ISR is a fixed address anyway
(for each prio) and it is up to the ISR to put a priority on how
the different sources are services (by the order the different
*IF flags are checked in the ISR).
The only "order" is the configurable high/low prio (if used).
And the PIC doesn't realy "look" for anything, this is hardwired
traditional logic, not some internal (sequencial) code. The
different interrupt sources are simply OR'ed together, more
Update -- this cannot be software related. I removed the TMR1H re-load so I'm getting 2-sec pulses, and incrementing seconds by 2 now. And I'm still going faster when the display is on, and clocking accurately when powered off. Must be noise related, but I'm going to swap crystal and caps (incrementally) to see if that may be the issues.
On 6/7/2012 3:04 PM, Neil wrote:
>>> other way around. All the best
> still going faster when the display is on, and clocking accurately
> when powered off
Are the crystal cases earthed ?
Do you have a filter on /mclr ?
Is Vcc well bypassed ?
|part 1 1007 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)
On 6/7/2012 8:51 PM, IVP wrote:
>> still going faster when the display is on, and clocking accurately
>> when powered off
> Are the crystal cases earthed ?
> Do you have a filter on /mclr ?
> Is Vcc well bypassed ?
Cases not earthed -- was not aware that that could/should be done.
Yes -- 0.1uf close to PIC power pins.
My mchip FAE had me scope the pins and it seems like it may be overdriven, as I'm being told I should have a sine wave, rather than square. See attached. At another point, I got the partial-sine waveform shown in next image. In sleep mode, I get the same partial-sine waveform. If this really is the issue now, then why is the wake-mode waveform it changing?
In the meanwhile, since this PIC was used for development (a lot of programming cycles, and frequent handling without static protection), I'm building a second board to see how that compares.
part 2 21538 bytes content-type:image/jpeg; name="XTAL-Wave-01.jpg" (decode)
part 3 18844 bytes content-type:image/jpeg; name="XTAL-Wave-03.jpg" (decode)
part 4 181 bytes content-type:text/plain; name="ATT00001.txt"
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
On 8 June 2012 17:17, Neil <narwani.org> wrote: picdude3
> My mchip FAE had me scope the pins and it seems like it may be overdriven,
> as I'm being told I should have a sine wave, rather than square. See
> attached. At another point, I got the partial-sine waveform shown in next
> image. In sleep mode, I get the same partial-sine waveform. If this really
> is the issue now, then why is the wake-mode waveform it changing?
That really is not good for a crystal oscillator! They're designed to
have only a single frequency going through them and not the mess of
harmonics which will be present with the square wave you're getting.
N.B. crystals are just very high Q filters.
My first thought is to try putting some resistance in series with the
crystal output pin on the PIC (SOSCO I think) to reduce the crystal's
-- Brendan Gillatt
> Cases not earthed -- was not aware that that could/should be
It has fixed occassional mysteries. Personally cured problems
caused by, such as, the position of wiring to an LED display,
and the proximity of a relay
> should have a sine wave, rather than square. See attached
eeeuuuuwwww. That's overdriven. Did you say this was the first
time you'd used these particular crystals with the 18F ?
Suggests 100k - 200k series resistor
Atmel, but would be relevant to PICs, see Section 4.2
> In sleep mode, I get the same partial-sine waveform. If this really
> is the issue now, then why is the wake-mode waveform changing?
Possibly the 32kHz crystal is broadcasting noise into the die or the
primary clock source
|Okay guys, I have a "fix" to this. I'll explain what I went about doing...
FAE visited me and spent several hours with me trying to fix this. Not sure what happened when I scoped it earlier (images I sent), but now we got a decently clean sine wave (when sleeping) and a bit of noise/shakiness when the display was on. PS lines showed some noise too. This time the equipment was moved to a desk with no other electronics, so I must've had something else being picked up previously. Noise-tested a similar circuit using a 16F1936 and the noise was a *bit* lower when awake. Definitely learned a lot about crystals and loading capacitances from him.
Anyway, we tried (a) earthing the crystal case; (b) using a cylindrical 32.768khz crystal instead of this SMD type (both of which I have used quite a bit before); (c) jumpering ground traces to stiffen the power lines, (d) changing/adding bypass caps and electrolytics on the power rails; (e) using a TO-220 7805 (as this is the first time I've used these TO-89 78L05CPK's); (f) using a TO-92 78L05, (g) adding series resistors of 140k and 280k; and none of these worked.
I did also try not updating TMR1H in the ISR to get 0.5-sec pulses (for the flashing colon) and instead just read TMR1H in the main code loop regularly to determine if the flashing colon should be on or off any time. Still no dice.
What worked is when I removed the TMR1H read in the mainloop. Apparently access this is causing some issue, and I've gone back to the datasheet and errata and still have not found anything that says this could be a problem. Yes I do have TMR1 set to 8-bit read/writes. I'm going to have to live with a static colon for now, but 1.5 days later it's still clocking accurately. I'll emailed the FAE so let's see what he finds out about it and I'll report back. Thanks for all the help.
On 6/8/2012 6:21 PM, IVP wrote:
Thanks for the update
What you/we've tried are good investigative measures, a pity
that the real answer was so out of left field
I forgot to mention one other thing that I tried -- to increase the value of the LED-drive resistors, so less current and hence less noise, but that did not solve it. This was before I figured out that accessing TMR1H was causing the problem.
However, I found another fix (other than not reading or writing TMR1H altogether)... apparently syncing the primary and secondary clocks work. I can read TMR1H (to determine state of the flashing colon), and clock works accurately.
On 6/10/2012 10:30 PM, IVP wrote:
> Thanks for the update
> What you/we've tried are good investigative measures, a pity
> that the real answer was so out of left field
> ... apparently syncing the primary and secondary clocks work
In my original reply I wrote - "The datasheet recommends stopping
the timer if it's asynchronous with the main ocillator before writing"
Knowing what you know now, does that fit in with your solution
More... (looser matching)
- Last day of these posts
- In 2012
, 2013 only
- New search...