Re: [volt-nuts] Prema 6048 Cal switch confusion

[David C. Partridge]

Randy, That's a very good thought.  I think it is OK in this case as the Error 
8 (checksum fail) occurs about 3 seconds after power on.

If necessary,  I think I could replace the MAX691 supervisory chip with one 
that holds the processor in reset for a bit longer (I think the MAX695 would 
probably be a 100% compatible replacement that holds the processor in reset for 
200mS instead of 50mS after Vcc reaches 4.7V  - PLEASE CORRECT me on this if I 
misread the datasheet).

Dave
 
-Original Message-
From: volt-nuts [mailto:volt-nuts-boun...@febo.com] On Behalf Of Randy Evans
Sent: 03 November 2017 17:17
To: Discussion of precise voltage measurement
Subject: Re: [volt-nuts] Prema 6048 Cal switch confusion

Dave,

Note the following from Maxim AN 202:

I Replaced My Standard SRAM with an NV SRAM and Now My System Doesn't Work at 
All. What Caused This?

In general, this is caused by one of two things:
First, the designer may not have considered the recovery time, or tREC, of the 
particular NV SRAM selected. On power-up, an internal power monitor disables 
the NV SRAM until a power-good situation and then holds it disabled for an 
additional 2ms (max) or 125ms (max), depending on the NV SRAM Page 5 of 9

after power-good. If the microcontroller attempts to access the memory before 
tREC times out, it will not be able to access the device's memory to read or 
write, so the system fails. Either a software loop on power-up to extend the 
access time past tREC, or moving the NV SRAM access somewhere later in the 
power-on initialization sequence in the microcontroller's firmware will resolve 
the problem. This problem often can be corrected by selecting a CPU supervisor 
that has a reset time longer than the recovery time of the NV SRAM.

Second, selecting the voltage levels at which the NV SRAM and the 
microcontroller become active is critical. If the microcontroller becomes 
active below 4.5V, and the NV SRAM becomes active above 4.75V, the same problem 
of the microcontroller trying to access a disabled NV SRAM occurs. The 
power-good threshold for the two devices should force the system to enable the 
NV SRAM first and then the processor. This involves selecting the NV SRAM with 
the appropriate power-good level and pairing that with a CPU supervisor that 
enables the processor at a higher voltage.

Some NV SRAMs have an active-low RESET output that is synchronous with its own 
internal reset. If this is used to reset the microcontroller, the possibility 
of trying to access a disabled NV SRAM is removed.

and:

Are Any NV SRAMs Not Recommended for Future Designs?

Yes. The DS1220Y and DS1225Y are not recommended for new designs. These older 
devices used a battery reference to determine the power-valid trip-point during 
power cycles. Newer designs use a band gap reference. The battery-referenced 
devices had a trip point that decreased during the life of the device. Devices 
using the band gap have a trip point that is stable for the life of the product.

The DS1220AD and DS1225AD are recommended for new designs needing the 
functionality of a 16kb or 64kb NV SRAM. For existing designs, the DS1220AD or 
DS1225AD may be considered as replacements; however, the "Y" parts had a reset 
timeout on the order of milliseconds while the "AD"
parts have a timeout of 125ms. When replacing the Y part with the AD part, it 
must be determined that the controlling processor does not become active during 
a power-up cycle for at least 125ms to ensure that the NV SRAM is available 
before the processor attempts a memory access.

Randy Evans

On Fri, Nov 3, 2017 at 2:54 AM, David C. Partridge < 
david.partri...@perdrix.co.uk> wrote:

> This gets odder and odder.   I put the new DS1220AD into the burner and
> read it.   Pretty random rubbish.
>
> So I cleared it to all FF and inserted into the meter set to Cal mode 
> and powered on - it apparently copied the default Cal constants to the NVRAM.
>
> However when I took it out again and looked at the content it didn't 
> look anything like what I'd read from the original NVRAM, and was 
> mostly still x'FF' but with blocks of ten bytes of zeros at x'100' 
> boundaries, followed by zeroes starting at x'6C7' to x'7ef' and what looks 
> like a checksum at
> x'7f0'.   I can't believe that these are cal constants specific to this
> meter!  Though they might be a set of default constants for any 6048!
>
> Filling it with all 00 resulted in an Error 8 (Checksum failure).
>
> I then programmed it with the data I had read from the DS1220Y (and had
> verified).   That also gave an Error 8.
>
> The data I read is attached in Intel Hex format.
>
> I'm wonder whether the meter is failing to read the original NVRAM in 
> a way that somehow passes checksumming
>
> Dave
> -Original Message-
> From: volt-nuts [mailto:volt-nuts-boun...@febo.com] On Behalf Of Tom 
> Miller
> Sent: 02 November 2017 19:05
> To: Discussion of precise voltage measurement
> Subject: Re: 

Re: [volt-nuts] Prema 6048 Cal switch confusion

[Randy Evans]

Dave,

Note the following from Maxim AN 202:

I Replaced My Standard SRAM with an NV SRAM and Now My
System Doesn't Work at All. What Caused This?

In general, this is caused by one of two things:
First, the designer may not have considered the recovery time, or tREC, of
the particular NV SRAM
selected. On power-up, an internal power monitor disables the NV SRAM until
a power-good situation
and then holds it disabled for an additional 2ms (max) or 125ms (max),
depending on the NV SRAM
Page 5 of 9

after power-good. If the microcontroller attempts to access the memory
before tREC times out, it will not
be able to access the device's memory to read or write, so the system
fails. Either a software loop on
power-up to extend the access time past tREC, or moving the NV SRAM access
somewhere later in the
power-on initialization sequence in the microcontroller's firmware will
resolve the problem. This problem
often can be corrected by selecting a CPU supervisor that has a reset time
longer than the recovery time
of the NV SRAM.

Second, selecting the voltage levels at which the NV SRAM and the
microcontroller become active is
critical. If the microcontroller becomes active below 4.5V, and the NV SRAM
becomes active above
4.75V, the same problem of the microcontroller trying to access a disabled
NV SRAM occurs. The
power-good threshold for the two devices should force the system to enable
the NV SRAM first and then
the processor. This involves selecting the NV SRAM with the appropriate
power-good level and pairing
that with a CPU supervisor that enables the processor at a higher voltage.

Some NV SRAMs have an active-low RESET output that is synchronous with its
own internal reset. If
this is used to reset the microcontroller, the possibility of trying to
access a disabled NV SRAM is
removed.

and:

Are Any NV SRAMs Not Recommended for Future Designs?

Yes. The DS1220Y and DS1225Y are not recommended for new designs. These
older devices used a
battery reference to determine the power-valid trip-point during power
cycles. Newer designs use a band
gap reference. The battery-referenced devices had a trip point that
decreased during the life of the
device. Devices using the band gap have a trip point that is stable for the
life of the product.

The DS1220AD and DS1225AD are recommended for new designs needing the
functionality of a 16kb
or 64kb NV SRAM. For existing designs, the DS1220AD or DS1225AD may be
considered as
replacements; however, the "Y" parts had a reset timeout on the order of
milliseconds while the "AD"
parts have a timeout of 125ms. When replacing the Y part with the AD part,
it must be determined that
the controlling processor does not become active during a power-up cycle
for at least 125ms to ensure
that the NV SRAM is available before the processor attempts a memory access.

Randy Evans

On Fri, Nov 3, 2017 at 2:54 AM, David C. Partridge <
david.partri...@perdrix.co.uk> wrote:

> This gets odder and odder.   I put the new DS1220AD into the burner and
> read it.   Pretty random rubbish.
>
> So I cleared it to all FF and inserted into the meter set to Cal mode and
> powered on - it apparently copied the default Cal constants to the NVRAM.
>
> However when I took it out again and looked at the content it didn't look
> anything like what I'd read from the original NVRAM, and was mostly still
> x'FF' but with blocks of ten bytes of zeros at x'100' boundaries, followed
> by zeroes starting at x'6C7' to x'7ef' and what looks like a checksum at
> x'7f0'.   I can't believe that these are cal constants specific to this
> meter!  Though they might be a set of default constants for any 6048!
>
> Filling it with all 00 resulted in an Error 8 (Checksum failure).
>
> I then programmed it with the data I had read from the DS1220Y (and had
> verified).   That also gave an Error 8.
>
> The data I read is attached in Intel Hex format.
>
> I'm wonder whether the meter is failing to read the original NVRAM in a
> way that somehow passes checksumming
>
> Dave
> -Original Message-
> From: volt-nuts [mailto:volt-nuts-boun...@febo.com] On Behalf Of Tom
> Miller
> Sent: 02 November 2017 19:05
> To: Discussion of precise voltage measurement
> Subject: Re: [volt-nuts] Prema 6048 Cal switch confusion
>
> How about copying the contents of the old nvram to the new one?
>
>
> - Original Message -
> From: "David C. Partridge" 
> To: "'Discussion of precise voltage measurement'" 
> Sent: Thursday, November 02, 2017 2:58 PM
> Subject: Re: [volt-nuts] Prema 6048 Cal switch confusion
>
>
> > Update - when I tried this I was using a brand new DS1220AD-100IND
> (blank)
> > to replace the DS1220Y.
> >
> > Reinstalling the DS1220Y and it worked as expected!  Processor must
> detect
> > cal mode by writing to NVRAM - if succeeds, then in Cal mode??? Maybe
> >
> > Is there some obscure incompatability between the DS1220AD and the
> > DS1220Y???
> >
> > Dave
> >
> > 

Re: [volt-nuts] Prema 6048 Cal switch confusion

[David C. Partridge]

This gets odder and odder.   I put the new DS1220AD into the burner and read 
it.   Pretty random rubbish.

So I cleared it to all FF and inserted into the meter set to Cal mode and 
powered on - it apparently copied the default Cal constants to the NVRAM.

However when I took it out again and looked at the content it didn't look 
anything like what I'd read from the original NVRAM, and was mostly still x'FF' 
but with blocks of ten bytes of zeros at x'100' boundaries, followed by zeroes 
starting at x'6C7' to x'7ef' and what looks like a checksum at x'7f0'.   I 
can't believe that these are cal constants specific to this meter!  Though they 
might be a set of default constants for any 6048!

Filling it with all 00 resulted in an Error 8 (Checksum failure).

I then programmed it with the data I had read from the DS1220Y (and had 
verified).   That also gave an Error 8.

The data I read is attached in Intel Hex format.

I'm wonder whether the meter is failing to read the original NVRAM in a way 
that somehow passes checksumming

Dave
-Original Message-
From: volt-nuts [mailto:volt-nuts-boun...@febo.com] On Behalf Of Tom Miller
Sent: 02 November 2017 19:05
To: Discussion of precise voltage measurement
Subject: Re: [volt-nuts] Prema 6048 Cal switch confusion

How about copying the contents of the old nvram to the new one?


- Original Message - 
From: "David C. Partridge" 
To: "'Discussion of precise voltage measurement'" 
Sent: Thursday, November 02, 2017 2:58 PM
Subject: Re: [volt-nuts] Prema 6048 Cal switch confusion


> Update - when I tried this I was using a brand new DS1220AD-100IND (blank) 
> to replace the DS1220Y.
>
> Reinstalling the DS1220Y and it worked as expected!  Processor must detect 
> cal mode by writing to NVRAM - if succeeds, then in Cal mode??? Maybe
>
> Is there some obscure incompatability between the DS1220AD and the 
> DS1220Y???
>
> Dave
>
> -Original Message-
> From: volt-nuts [mailto:volt-nuts-boun...@febo.com] On Behalf Of David C. 
> Partridge
> Sent: 02 November 2017 18:23
> To: 'Discussion of precise voltage measurement'
> Subject: [volt-nuts] Prema 6048 Cal switch confusion
>
> I've got a Perma 6048 that I've trying to put into Cal mode.  It just 
> won't!
>
> The switch on the rear panel works OK, AFAICT when in the Cal position it 
> connects ~WE on the DS1220 (pin 21) and ~W on the $864 SRAM (pin 27) to a
> 4K7 pullup to +5V and to the output of an LS00 which should be strobing 
> the
> Write lines low as needed.   I can't see any way in which the processor 
> can
> be informed of the switch setting!  In measure mode it just connects ~WE 
> on the DS1220 to a 10k pullup to +5V.
>
> The schematic is on page 120 (Figure 11.4) of the user manual and also 
> page
> 9-7 of the service manual.
>
> Clearly I'm missing something - as a friend reports that his does go into 
> cal mode.
>
> Confused ...
> Thanks
> Dave
>
> ___
> volt-nuts mailing list -- volt-nuts@febo.com To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
> and follow the instructions there.
>
> ___
> volt-nuts mailing list -- volt-nuts@febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
> and follow the instructions there. 

___
volt-nuts mailing list -- volt-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.


Prema 6048 sn 1019 DS1220Y Cal Constants.hex
Description: Binary data


Cal Constants from ROM.hex
Description: Binary data
___
volt-nuts mailing list -- volt-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/volt-nuts
and follow the instructions there.