Agilent 33120A function generator -- Error 771

[Signal32]

Hello,

Today my Agilent 33120A suddenly started booting with the "Err" indicator lit up. It happened after i powered it off, waited ~10 seconds then powered it on again.
Looking at the error codes, it shows only error 771.
Here is what Agilent says on their website about this error:

Error 771, "Nonvolatile cal memory checksum error" is most often due to some type of calibration error, e.g. an incomplete or improperly performed calibration routine.

If you have the needed equipment to perform a calibration of the instrument as described in the 33120A Service Guide, doing so may resolve your problem. The 33120A Service Guide is available as part number 33120-90014. 33120A Function Generator Service Guide

If you do not have the proper equipment available to perform a calibration, or if the instrument continues to display error code 771 after calibration, your local Agilent Instrument Support Center should be contacted for instructions on how to get the instrument repaired or recalibrated. Find your local Agilent contact at www.tm.agilent.com Click on assistance and choose your geographic location.

Self-test passes, the error happens at power on. The function generator still works, but presumably without using any calibration constants.
I looked inside and there doesn't seem to be any battery-backed nonvolatile memory in there. So I'm guessing the failure is inside a flash chip.

Has anyone had any experience with this type of issue ? Does anyone have any suggestions ? I'm thinking that even if I send it in for calibration the error won't go away since it happened so randomly.

Thanks!

[caiser01]

Apologies for resurrecting an old thread but I experienced the same issue with an HP 33120A today and was able to resolve it painlessly.

I just purchased one of these units on ebay and it arrived today. On first power up, everything worked but the 'Err' indicator was lit. Digging into the menus revealed the single error code 771. Unit passed the self-test with no errors. After finding this thread and digging a bit in the service manual, I was investigating the possibility of calibrating this unit. During that process, I stumbled on to a solution by following this process:

1. Under the CAL menu, set the unit to 'UNSECURED' (default passcode is 033120; procedure described on page 47 of the service manual)
2. With the unit now in the 'UNSECURED' state, power it off.
3. Wait a few seconds and power back on.
4. Check the CAL menu and verify the unit is still 'UNSECURED'.
5. Set the unit back into the 'SECURED' state (again default passcode 033120)
6. Power off, wait a few seconds, power back on. No more Error 771!

It's possible your unit may have had the passcode changed to something other than the default. If so you'll have to open the case and short the pads at JM101 as described on page 65 of the service manual in order to bypass the code.

Basically, we're unsecuring to perform a calibration but then resecuring without calibrating anything. Not certain why this resolved error 771 but my theory is that the act of securing the device perhaps recalculates the offending "Nonvolatile cal memory checksum" to a valid value.

YMMV but just wanted to share this as a possible resolution for anyone else who may have experienced this scenario.

Incidentally, I did run through the quick check procedures outlined in the service manual and my HP 33120A appears to be functioning correctly within spec.

[Yansi]

just a note - if the units store the CAL data within a battery powered SRAM, it as well may be possible, the battery is dead and the SRAM on the edge of loosing its content. Hence why the corrupted data detected by an incorrect chksum. So even though you clear the error, the cal may in fact be corrupted.

I would at least check the unit thoroughly, if it is withing the spec, if not trying to recal it, as most likely the cal is long long time due.

[TheSteve]

There is no battery inside a 33120A. Odds are some value was corrupted in cal memory.  Unlocking and relocking etc recalculated the checksum for that data. So something in the cal data was changed and could be off unless it was the actual checksum value itself that had become corrupted. It may still function perfectly or something may be slightly off, or even off a decent amount but finding that could be quite the challenge.