Well, it turns out that either the first errata item applies to my
scenario (though the wording seems to indicate otherwise), or I have
actually discovered a new high sleep current bug in the chip. I have
the CONFIG word set to use the internal oscillator block (INTRC_IO).
This means that the PIC starts at 31.25 khz. Therefore right after
startup, I do this:
movlw b'01110000' ; Set internal osc to 8Mhz
movwf OSCCON & 0x7F
The errata sheet (DS80171f) indicates that a high sleep current will
occur if you:
"CONDITION: FOSC<2:0> (Configuration Word
Register 1) bits are configured for any oscillator
selection other than the internal RC oscillator. <----- Note "other
than"
PROCEDURE:
1. Clock switch occurs anywhere in the application
code where the internal RC oscillator is
selected via the SCS bits (‘10’).
2. Sleep mode is entered while the SCS bits are
configured for the internal RC oscillator (‘10’).
Work around
Before Sleep mode is entered, configure or clear
the SCS bits (‘00’) to switch back to the primary
clock source that is defined by FOSC<2:0>
(Configuration Word Register 1)."
I don't meet the CONDITION clause because I have FOSC<2:0> set to use
the INTRC (internal oscillator block). I also don't believe that the
SCS bits are '10' since I specifically set them to '00' when I load
OSCCON to switch to 8mhz. However, when I do the work around by doing
this in the code:
bsf STATUS, RP0 ; BANK 1
clrf OSCCON ; Slow way down for errata
to acheive low current sleeping
nop
sleep
nop
movlw b'01110000' ; Set internal osc back to
8Mhz
movwf OSCCON & 0x7F
bcf STATUS, RP0 ; BANK 0
my sleep current drops to ~3uA instead of the 120uA I had been
experiencing. Hallelujah
So, does this look like a bug in the silicon?
PS:
I really wish microchip would firm up their terminology on the internal
oscillator block. I quote this from the datasheet:
"Throughout this data sheet, when referring
specifically to a generic clock source, the
term “INTRC” may also be used to refer to
the clock modes using the internal oscillator
block. This is regardless of whether the
actual frequency used is INTOSC
(8 MHz), the INTOSC postscaler, or
INTRC (31.25 kHz)."
People considering using the 16F88 may wish to fully study the errata
since the IOFS bit (which is supposed to indicate clock stability after
a switch in speed) is worthless according to item 2. Item 3 in the
errata should be particularly interesting.
> Hello all,
>
> I've been tinkering with sleep mode on my data logger project and I
seem
> to be having some trouble. I can't get the sleep current on the PIC
to
> less than 120uA while it is sleeping, it should be less than 5uA. I
> don't have the PORTB pull-ups on, nor do I have the comparators or
their
> Vref on. No floating input pins, no "loaded" output pins. I've tried
> turning the ADC completely off but that makes virtually no difference
> (just like the datasheet indicates). No ADC conversions are taking
> place while I sleep. I'm using the internal oscillator at 8Mhz. MCLR
> is disabled and tied to ground. Brown out is disabled and watch dog
is
> disabled. No timers are being used. I wake up with RB0 interrupts
once
> per second and that's all working perfectly.
>
> I'm measuring current at the Vcc pin of the PIC. My meter is not the
> greatest in the world, but it seems capable of giving me reasonable
> readings at lower currents than 120uA. Any ideas as to what I have
> missed? The only things I specifically enabled are: the ADC, RB0
ints,
> the UART in async mode.
>
> -
Item 1 is still worded the same way (whether that's because
the wording isn't actually a problem or it is and MC know
but haven't fixed it yet, can't say)
> Glad to hear you've got to the bottom of it
>
> Item 1 says -
>
> A high Sleep current will exist when the following
> condition is met and procedures are followed:
>
> IYE, how relevant/important is the "and"
Since we're all programmers and I don't think lawyers wrote the
datasheet, I tend to think that it means AND. ;-) My stance is that I
don't meet the initial CONDITION so (as any good C parser would do) I
shouldn't have to bother even reading the PROCEDURE clause. IOW, 'and'
means 'and' in an 'if' statement kinda way.
> Item 1 is still worded the same way (whether that's because
> the wording isn't actually a problem or it is and MC know
> but haven't fixed it yet, can't say)
I still contend that my specific scenario is entirely different from
what the errata specifies.
> Rev G (2/2005)
>
> "Removed Data Sheet Clarification issues."
>
> Issues ? What does that mean ?
Is it just me, or does it seem like the documentation writers are going
downhill? It just seems like the older datasheets were more clear and
less ambiguous. I've even seen obvious errors (like the max spec for
something being less than the typical) and sample code for a peripheral
that doesn't work (like Howard H recently experienced).
On Mon, 2005-03-28 at 07:27 -0600, michael brown wrote:
> Is it just me, or does it seem like the documentation writers are going
> downhill? It just seems like the older datasheets were more clear and
> less ambiguous. I've even seen obvious errors (like the max spec for
> something being less than the typical) and sample code for a peripheral
> that doesn't work (like Howard H recently experienced).
I don't think it's just you.
Another example that I once hit is this: what is the speed of the
internal oscilator on the dsPIC?
If you check the datasheet there are a few places where the speed is
alluded to. For example in the 4011 datasheet:
In table 21-1 (oscillator operating modes): FRC 8MHz internal RC
oscillator (with an odd 7.5MHz for the 16X PLL, I thought that was just
a typo).
In section 21.2.5 (Fast RC Oscillator) it says 8MHz nominal.
Table 24-5: FRC (~2MIPS)
So, you would THINK that the FRC runs at 8MHz (thereabouts).
Well, imagine my surprise when I do some RS232 and nothing is working
right. A check with the scope shows the bits are longer then expected.
I fiddle and fiddle, finally getting the bit time correct. Doing some
reverse calculation I find that the PIC appears to be actually running
at about 7.4MHz. Odd, my 2011 runs at almost exactly 8MHz, as does a
6010 (I think, could be a 6012, can't remember) I had...
So, going to the "accuracy" section of the datasheet (thinking the RC in
the dsPIC is horribly out of whack) I find this table:
Table 24-13: Oscillator Frequency - FRC - typical: 7.3728MHz??!??!?
Of course, some might say it's my fault, I should have checked the WHOLE
datasheet, and they'd be right in a small way. But come on, something
like that is just incredible.
Herbert Graf wrote:
> In table 21-1 (oscillator operating modes): FRC 8MHz internal RC
> oscillator (with an odd 7.5MHz for the 16X PLL, I thought that was just
> a typo).
>
> In section 21.2.5 (Fast RC Oscillator) it says 8MHz nominal.
>
> Table 24-5: FRC (~2MIPS)
This is probably because the oscillator frequency was changed and they
neglected to update the various mentions to it in the main part of the
manual, with only the real spec in the back getting updated.
The reason for the change is that 8MHz is just a little too fast to use with
the 16x PLL. The max it can take is 7.5MHz. So the oscillator became
roughly "7.5MHz", except that 7.3728MHz is the next lower "baud rate"
frequency. For some reason I can't imagine, the high speed baud rate mode
was dropped from the dsPICs, so having a frequency that is a multiple of
standard baud rates is more important than it would otherwise be. Note that
7.3728MHz is also the standard crystal frequency for running a dsPIC at
"maximum" speed.
> Table 24-13: Oscillator Frequency - FRC - typical: 7.3728MHz??!??!?
Yeah, plus or minus what? Specifying an RC oscillator to 5 digits is just
irresponsible, even if it is a typical spec.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
On Mon, 2005-03-28 at 13:57 -0500, Olin Lathrop wrote:
> Herbert Graf wrote:
> > In table 21-1 (oscillator operating modes): FRC 8MHz internal RC
> > oscillator (with an odd 7.5MHz for the 16X PLL, I thought that was just
> > a typo).
> >
> > In section 21.2.5 (Fast RC Oscillator) it says 8MHz nominal.
> >
> > Table 24-5: FRC (~2MIPS)
>
> This is probably because the oscillator frequency was changed and they
> neglected to update the various mentions to it in the main part of the
> manual, with only the real spec in the back getting updated.
Yup, which of course makes one wonder: what else did they get wrong! :(
> The reason for the change is that 8MHz is just a little too fast to use with
> the 16x PLL. The max it can take is 7.5MHz. So the oscillator became
> roughly "7.5MHz", except that 7.3728MHz is the next lower "baud rate"
> frequency. For some reason I can't imagine, the high speed baud rate mode
> was dropped from the dsPICs, so having a frequency that is a multiple of
> standard baud rates is more important than it would otherwise be. Note that
> 7.3728MHz is also the standard crystal frequency for running a dsPIC at
> "maximum" speed.
Yes, I noticed that, very frustrating, I guess MChip just didn't think
many people would use a dsPIC at standard USART rates.
I don't mind the fact they changed the FRC to that freq, but if they
would only change the documentation properly!??
> > Table 24-13: Oscillator Frequency - FRC - typical: 7.3728MHz??!??!?
>
> Yeah, plus or minus what? Specifying an RC oscillator to 5 digits is just
> irresponsible, even if it is a typical spec.
> On Mon, 2005-03-28 at 07:27 -0600, michael brown wrote:
>> Is it just me, or does it seem like the documentation writers are going
>> downhill? It just seems like the older datasheets were more clear and
>> less ambiguous. I've even seen obvious errors (like the max spec for
>> something being less than the typical) and sample code for a peripheral
>> that doesn't work (like Howard H recently experienced).
I think that you can expect that to get worse as complexity increases.
It's built into the system. More features, lower price, # of testers
does not increase proportionally (it can't, because of the price and
time constraints) = more errors in silicon and more errors in
documentation (and more shortage of people who can solve problems
since evryting is ever-changing).
houston.rr.com>
