Looking at the description of the Starpoint status, it would appear that bits 2 (EEprom failure) and 4 (Program Integrity) represent serious problems.
After some engineering use we are finding that the Program Integrity bit seems to be "fragile". After a relatively short time all our meters start to report this fault.
Do you have any opinion as to why this occurs, how we could prevent it and what we should do after it does happen?
Starpoint Meter Error
Moderators: aardvark, davebush, Admin
Having raised the Topic with the manufacturer, the situation appears to be
that the error status of 0x30 that we get represents a "genuine" fault.
(Although it occurs often enough that they wonder why)
The actual reply I got was:
This has occured previously, and we have included a procedure at
manufacturing time to monitor this.
On power up, the SEC processor runs a routine that verifies the 8 bit
checksum of the program contents. This checksum is compared to a known
value, and if incorrect then flags the 'integrity suspect' bit.
The SEC is tested for this condition at manufacture. If this message occurs
during use, then it is probable that either a) the unit has suffered static
damage, and program contents have been affected, or b) the processor
had a manufacturing fault that has caused an error in the program contents at a later time.
Depending on where the fault lies within the program, dictates where an
error may occur. This fault could potentially cause the SEC to malfunction,
the SEC should be checked on each power up, as is stated in the info pack.
Unfortunately, the Toshiba processor can't be read, as a 'fuse' in the
component is blown once programming is completed. This fuse acts as a
security device that prevents re-programming.
We continue to test the 'status' command at manufacturing stage.
that the error status of 0x30 that we get represents a "genuine" fault.
(Although it occurs often enough that they wonder why)
The actual reply I got was:
This has occured previously, and we have included a procedure at
manufacturing time to monitor this.
On power up, the SEC processor runs a routine that verifies the 8 bit
checksum of the program contents. This checksum is compared to a known
value, and if incorrect then flags the 'integrity suspect' bit.
The SEC is tested for this condition at manufacture. If this message occurs
during use, then it is probable that either a) the unit has suffered static
damage, and program contents have been affected, or b) the processor
had a manufacturing fault that has caused an error in the program contents at a later time.
Depending on where the fault lies within the program, dictates where an
error may occur. This fault could potentially cause the SEC to malfunction,
the SEC should be checked on each power up, as is stated in the info pack.
Unfortunately, the Toshiba processor can't be read, as a 'fuse' in the
component is blown once programming is completed. This fuse acts as a
security device that prevents re-programming.
We continue to test the 'status' command at manufacturing stage.
-
Rick
So far as "ignoring errors", the one we're thing of ignoring is probably the most significant! I suggest you use a MeterStatus of 3 as a warning to the user that the meter may not be functioning correctly, but may be fine.
I don't think Starpoint recommend ignoring the fault - they actually recommend not hot swapping the meters.
I don't think Starpoint recommend ignoring the fault - they actually recommend not hot swapping the meters.
I should first of all emphasise that this is a problem internal to the Starpoint SEC, not our equipment.
Having just been talking to Starpoint recently, they seem now to concede that this problem can just arise spontaneously and that it doesn't have any effect on meter functionality. I believe that their current recommendation is to ignore this fault unless you can observe actual problems.
Having just been talking to Starpoint recently, they seem now to concede that this problem can just arise spontaneously and that it doesn't have any effect on meter functionality. I believe that their current recommendation is to ignore this fault unless you can observe actual problems.