Lpc2000

I'm seeing some odd behaviour in the VPB registers that I haven't been able 
to track down so far.  So I thought I would check to see if anyone else had 
run across it yet.  The following is a code fragment I'm using to read the 
VPB divider so that I can determine the clock speed the peripherals see.

  *ptr = (VPB_param)VPBDIV;/*lint !e930*/
  switch( VPBDIV & 0x3) {
     case VPB_DIV_ONE:
          *ptr =  VPB_DIV1;
          break;

     case VPB_DIV_HALF:
          *ptr =  VPB_DIV2;
          break;

     case VPB_DIV_QUARTER:
          *ptr =  VPB_DIV4;
          break;

     default:
          r->_errno = EINVAL;
          return -1;
     }
  return 0;

Notice that I'm reading the divider twice.  The first time is just thrown 
away.  If I remove that first read and just use the one in the switch I get 
an incorrect result.  The assembly output does appear to be correct.

Anyone seen anything like this before?  I don't have a nice short 
reproducible test case yet.  For now I'm living with the workaround but I'm 
worried about what else may be lurking out there.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Yes, I have also had problems reading the VPB registers. Sometimes I 
need to read more than twice. But writin the register seems to work 
without problems.

Jon Vedum


--- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> I'm seeing some odd behaviour in the VPB registers that I haven't 
been able 
> to track down so far.  So I thought I would check to see if anyone 
else had 
> run across it yet.  The following is a code fragment I'm using to 
read the 
> VPB divider so that I can determine the clock speed the peripherals 
see.
> 
>   *ptr = (VPB_param)VPBDIV;/*lint !e930*/
>   switch( VPBDIV & 0x3) {
>      case VPB_DIV_ONE:
>           *ptr =  VPB_DIV1;
>           break;
> 
>      case VPB_DIV_HALF:
>           *ptr =  VPB_DIV2;
>           break;
> 
>      case VPB_DIV_QUARTER:
>           *ptr =  VPB_DIV4;
>           break;
> 
>      default:
>           r->_errno = EINVAL;
>           return -1;
>      }
>   return 0;
> 
> Notice that I'm reading the divider twice.  The first time is just 
thrown 
> away.  If I remove that first read and just use the one in the 
switch I get 
> an incorrect result.  The assembly output does appear to be correct.
> 
> Anyone seen anything like this before?  I don't have a nice short 
> reproducible test case yet.  For now I'm living with the workaround 
but I'm 
> worried about what else may be lurking out there.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

Again, proof that this group is on the cutting edge of LPC2100 
development.  ;-)  The VPBDIV read problem is official, official 
philips description:

The problem of read of VPBDIV register is confirmed: read of VPBDIV 
register may return a wrong  value. The workaround is to read the 
VPBDIV register twice consecutively and the second read always 
returns the correct value. The write to VPBDIV, the function of 
VPBDIV and the other VPB/AHB registers are not affected.

Richard

--- In lpc2100@yahoogroups.com, "jvedum" <j.vedum@o...> wrote:
> Yes, I have also had problems reading the VPB registers. Sometimes 
I 
> need to read more than twice. But writin the register seems to work 
> without problems.
> 
> Jon Vedum
> 
> 
> --- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...> 
> wrote:
> > I'm seeing some odd behaviour in the VPB registers that I haven't 
> been able 
> > to track down so far.  So I thought I would check to see if 
anyone 
> else had 
> > run across it yet.  The following is a code fragment I'm using to 
> read the 
> > VPB divider so that I can determine the clock speed the 
peripherals 
> see.
> > 
> >   *ptr = (VPB_param)VPBDIV;/*lint !e930*/
> >   switch( VPBDIV & 0x3) {
> >      case VPB_DIV_ONE:
> >           *ptr =  VPB_DIV1;
> >           break;
> > 
> >      case VPB_DIV_HALF:
> >           *ptr =  VPB_DIV2;
> >           break;
> > 
> >      case VPB_DIV_QUARTER:
> >           *ptr =  VPB_DIV4;
> >           break;
> > 
> >      default:
> >           r->_errno = EINVAL;
> >           return -1;
> >      }
> >   return 0;
> > 
> > Notice that I'm reading the divider twice.  The first time is 
just 
> thrown 
> > away.  If I remove that first read and just use the one in the 
> switch I get 
> > an incorrect result.  The assembly output does appear to be 
correct.
> > 
> > Anyone seen anything like this before?  I don't have a nice short 
> > reproducible test case yet.  For now I'm living with the 
workaround 
> but I'm 
> > worried about what else may be lurking out there.
> > 
> > Robert
> > 
> > " 'Freedom' has no meaning of itself.  There are always 
> restrictions,
> > be they legal, genetic, or physical.  If you don't believe me, 
try 

> to
> > chew a radio signal. "
> > 
> >                          Kelvin Throop, III

At 06:14 PM 1/14/04 +0000, you wrote:
>Again, proof that this group is on the cutting edge of LPC2100
>development.  ;-)  The VPBDIV read problem is official, official
>philips description:
>
>The problem of read of VPBDIV register is confirmed: read of VPBDIV
>register may return a wrong  value. The workaround is to read the
>VPBDIV register twice consecutively and the second read always
>returns the correct value. The write to VPBDIV, the function of
>VPBDIV and the other VPB/AHB registers are not affected.

I feel a lot better now :)  Really I do.  I hate setting something up as 
"It seems to work", sooner or later the underlying problem will unmask 
itself and reappear.

Now I can add a proper comment (and pointer to official documentation) so 
that some poor benighted soul (me) doesn't 'optimize' the work around away.

Thanks for the update Richard.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 06:14 PM 1/14/04 +0000, you wrote:
>Again, proof that this group is on the cutting edge of LPC2100
>development.  ;-)  The VPBDIV read problem is official, official
>philips description:
>
>The problem of read of VPBDIV register is confirmed: read of VPBDIV
>register may return a wrong  value. The workaround is to read the
>VPBDIV register twice consecutively and the second read always
>returns the correct value. The write to VPBDIV, the function of
>VPBDIV and the other VPB/AHB registers are not affected.

Richard, where did you find this?  I'm updating my comments so I can 
include a reference to this but I can't seem to find it.  The errata sheet 
does include a note about an SPI problem but I didn't see anything about 
VPBDIV.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

It came straight from Philips, it hasn't made the errata yet.

Richard

--- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 06:14 PM 1/14/04 +0000, you wrote:
> >Again, proof that this group is on the cutting edge of LPC2100
> >development.  ;-)  The VPBDIV read problem is official, official
> >philips description:
> >
> >The problem of read of VPBDIV register is confirmed: read of VPBDIV
> >register may return a wrong  value. The workaround is to read the
> >VPBDIV register twice consecutively and the second read always
> >returns the correct value. The write to VPBDIV, the function of
> >VPBDIV and the other VPB/AHB registers are not affected.
> 
> Richard, where did you find this?  I'm updating my comments so I 
can 
> include a reference to this but I can't seem to find it.  The 
errata sheet 
> does include a note about an SPI problem but I didn't see anything 
about 
> VPBDIV.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

Thanks Richard.  I'll keep my eyes open.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III