> Do you think that is problem? I assumed that
> Microchip knew their stuff and when you set a
> PIC to internal RC osc and internal MCLR control
> this would be ok. After all, it's not hard to
> start up an RC osc is it?
> -Roman
>
>
> Bob Ammerman wrote:
> >
> > 150ms sounds pretty slow for a Vdd rise time to me.
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
> >

> > Do you think that is problem? I assumed that
> > Microchip knew their stuff and when you set a
> > PIC to internal RC osc and internal MCLR control
> > this would be ok. After all, it's not hard to
> > start up an RC osc is it?
> > -Roman
> >
> >
> > Bob Ammerman wrote:
> > >
> > > 150ms sounds pretty slow for a Vdd rise time to me.
> > >
> > > Bob Ammerman
> > > RAm Systems
> > > (contract development of high performance, high function, low-level
> > > software)
> > >

> > PIC and it should work.
>
>
> Thanks Marcelo! Are you sure that is what it was?
> Unfortunately my circuit is going to have a slightly
> slow Vdd rise, the hardware design is finalised.
>
> I really didn't think the RC osc would be fussy with
> Vdd rise... If you can offer any more info about your
> experiences with this that would be great! :o)
> -Roman

> > I assumed that Microchip knew their stuff and when you set a PIC
> > to internal RC osc and internal MCLR control this would be ok.
> > After all, it's not hard to start up an RC osc is it?
>
> Roman:
>
> The failure of the RC oscillator is just a symptom of your REAL
> problem, which is either that your Vdd rise time is too long or that
> Vdd isn't starting its rise from < 0.7V.
>
> You only characterized your rise time as "less than" 150 ms. I don't
> have a datasheet here, but I recall that Microchip's specified
> Minimum Vdd Rise Rate is 0.05V/ms.
>
> Are you sure that your PIC's power supply is dropping to below 0.7V
> before you switch it on?

> ALL low-end PICmicro MCUs will always have the MSB or more MSBs set in the
> FSR at all times, depending on how many register banks are built into the
> device.  This means that the PIC12C50x, PIC16C505, PIC16C5x will all have
> one or more FSR bits always set.
>
> But, the PIC12C67x, PIC16C55x are mid-range architected parts and the FSR
> can have all its bits reset to zero.

> Also make sure you mark the PIC12C50x datasheets as well.

> Thank you Andy and everyone else who helped! :o)
> I did my homework last night and tracked it down.
> My actual Vdd rise time is less than 70mS to
> reach 95% of Vdd. The datasheet spec is 0.05v/mS
> (100mS at 5v supply) so this is fine. I also hold
> all pins as outputs and set to low, which reduces
> the chance of startup latchup.
>
> After checking all my hardware I realised there
> was a software bug, caused by Microchip's shoddy
> documentation (Grrrrr!)
>
> With the 16c505 the FSR register bit7 CANNOT be
> cleared. Unlike other PICs. This is not mentioned
> in the datasheet anywhere, I found it with the
> simulator. Very nasty, the first thing I do on
> startup is clear all ram registers, using the
> typical FSR loop, and while I know FSR is only a
> 7 bit register (bit7 is unused), but whenever you
> read it to see where it is up to bit7 reads
> as 1.
>
> Very nasty, I don't mind software bugs when they
> are my fault, but that annoys me a lot...
> I have put big red notes on all the
> applicable pages in my 16c505 datasheet. :o(
> -Roman
>
>
>
>
>
>
> Andrew Warren wrote:
>
> > > I assumed that Microchip knew their stuff and when you set a PIC
> > > to internal RC osc and internal MCLR control this would be ok.
> > > After all, it's not hard to start up an RC osc is it?
> >
> > Roman:
> >
> > The failure of the RC oscillator is just a symptom of your REAL
> > problem, which is either that your Vdd rise time is too long or that
> > Vdd isn't starting its rise from < 0.7V.
> >
> > You only characterized your rise time as "less than" 150 ms. I don't
> > have a datasheet here, but I recall that Microchip's specified
> > Minimum Vdd Rise Rate is 0.05V/ms.
> >
> > Are you sure that your PIC's power supply is dropping to below 0.7V
> > before you switch it on?
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>
>

>
> Roman Black <RemoveMEPICLISTspam_OUTKILLspammitvma.mit.edu> wrote:
>
> > So what happened to the Microchip convention that unused bits read
> > as zeros???
>
> Roman:
>
> The 16C505's FSR-register behavior (along with the datasheet's
> description of it as "a 5-bit register") is left over from the 16C54.
>
> On that part, it made sense to hardwire the upper bits to 1, since it
> allowed loops like this one, which clears all 16C54 RAM, to be short
> and fast:
>
>       MOVLW   PORTA
>       MOVWF   FSR
>
>     LOOP:
>
>       CLRF    INDF
>       INCFSZ  FSR
>       GOTO    LOOP
>
> If the upper bits were hardwired to 0, INCFSZ would cease to work on
> the FSR register, so the above loop would have to become:
>
>     LOOP:
>
>       CLRF    INDF
>       INCF    FSR
>       TSTF    FSR
>       SKPZ
>       GOTO    LOOP
>
> It's not a BIG deal... But I guess the guys who'd been contracted to
> design the PIC figured that, since it didn't cost anything to
> hardwire those bits to 1, it was better not to break the INCFSZ
> instruction.  Also, if the larger-RAM PICs that the C54's designers
> had anticipated had been designed with contiguously-addressed RAM,
> hardwiring the upper bits to 1 would have made code portable from the
> 54 to other PICs.
>
> -Andy
>
> === Andrew Warren --- RemoveMEaiwTakeThisOuTspamcypress.com
> === IPD Systems Engineering, CYSD
> === Cypress Semiconductor Corporation
> ===
> === Opinions expressed above do not
> === necessarily represent those of
> === Cypress Semiconductor Corporation
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.