Loading ...
Sorry, an error occurred while loading the content.

Partial Amnesia in Eproms

Expand Messages
  • Declan Moriarty
    I am repairing 2 Boards from the same device with ST 27C256B eproms in them, and both of the eproms have a form of partial amnesia. Put them in a programmer,
    Message 1 of 6 , Jun 15, 2006
    • 0 Attachment
      I am repairing 2 Boards from the same device with ST 27C256B eproms in
      them, and both of the eproms have a form of partial amnesia. Put them in
      a programmer, take a checksum, and they return a different figure each
      time it is done. This is not a standard failure mode, I might add. They
      originally ware programmed with the same program, but different batch
      dates

      In a buffer editor, they appear to have random bytes 0f 00 and FF added
      in the lower portion, although they seem intact higher up. I am left now
      looking for a copy of the program intact

      Any idea what causes this? This is the second time I have run into this
      phenomonon, as another factory had memory chips that lost it in nearly
      every machine. I'd _love_ to know what'#s behind it. You can dismiss
      poor programming - the source is impeccable.
      --
      With Best Regards,

      Declan Moriarty.
    • docydoc
      How old are the eproms? To be more precise how long has it been since they were programmed? And are they nmos or already cmos? Pierre
      Message 2 of 6 , Jun 15, 2006
      • 0 Attachment
        How old are the eproms? To be more precise how long has it been since
        they were programmed?
        And are they nmos or already cmos?

        Pierre

        Declan Moriarty wrote:

        >I am repairing 2 Boards from the same device with ST 27C256B eproms in
        >them, and both of the eproms have a form of partial amnesia. Put them in
        >a programmer, take a checksum, and they return a different figure each
        >time it is done. This is not a standard failure mode, I might add. They
        >originally ware programmed with the same program, but different batch
        >dates
        >
        >In a buffer editor, they appear to have random bytes 0f 00 and FF added
        >in the lower portion, although they seem intact higher up. I am left now
        >looking for a copy of the program intact
        >
        >Any idea what causes this? This is the second time I have run into this
        >phenomonon, as another factory had memory chips that lost it in nearly
        >every machine. I'd _love_ to know what'#s behind it. You can dismiss
        >poor programming - the source is impeccable.
        >
        >
      • Pieter Hoeben
        Hi, ... I think it is strange that whole bytes change. I would expect single bits to fail. What may have happened is fast programming . In the old times
        Message 3 of 6 , Jun 15, 2006
        • 0 Attachment
          Hi,

          > Declan Moriarty wrote:
          >I am repairing 2 Boards from the same device with ST 27C256B eproms in
          >them, and both of the eproms have a form of partial amnesia. Put them in
          >a programmer, take a checksum, and they return a different figure each
          >time it is done. This is not a standard failure mode, I might add. They
          >originally ware programmed with the same program, but different batch
          >dates
          >In a buffer editor, they appear to have random bytes 0f 00 and FF added
          >in the lower portion, although they seem intact higher up. I am left now
          >looking for a copy of the program intact
          >Any idea what causes this? This is the second time I have run into this
          >phenomonon, as another factory had memory chips that lost it in nearly
          >every machine. I'd _love_ to know what'#s behind it. You can dismiss
          >poor programming - the source is impeccable.

          I think it is strange that whole bytes change. I would expect
          single bits to fail.

          What may have happened is "fast programming". In the old times
          eproms needed times like 10 msec up to 50 msec a byte for
          programming. This is fact charges some internal capacitors.
          Newer eproms are much faster.

          Anhd then sombody got the idea: what if we program it for
          for example 5 msec, and then check if it is ok? If not do
          it some more. This indeed made programming faster. But
          may also lead to not fully charged capacitors. This can
          seriously degrade data retention (should be something like
          10 years or 100 years, depending on the device).

          Though here I expect a different problem. Glitches at powerup
          that may lead to a write action would give hex 00 bytes.
          Erased bytes would give hex FF bytes. As you see both,
          I have no real expanation. do you really see both?

          Regards,
          Pieter
          ______________________________________________

          Hoeben Electronics Phone: +31 6 51590081
          Ronkert 44 Fax: +31 13 5096025
          5094 EW Lage Mierde Private: +31 13 5096200
          The Netherlands E-mail: info@...
          http://www.hoeben.com Skype: HoebenElectronics
          Chamber of Commerce (KvK Oost Brabant): 18038394
          ______________________________________________
        • docydoc
          @Declan: Claiming to the ideas of what Pieter wrote: Have the eproms been exposed to radioactivity or xray or strong or high frequency electric fields or
          Message 4 of 6 , Jun 15, 2006
          • 0 Attachment
            @Declan:

            Claiming to the ideas of what Pieter wrote:

            Have the eproms been exposed to radioactivity or xray or strong or high
            frequency electric fields
            or something similar? This all may lead to failures you were talking about.
            (I remember erasing some OTP-chips some years ago using xray :-)

            nmos data retention is given by numerous manufacturers with "at least"
            10 years. Nobody knows what happens then.
            newer cmos last longer. Have not found data retention analysis based on
            different programming algo but
            agree with Pieter. Take a look at the microchip site they have had
            article about data retention and how to get maximum
            write cycles.

            Pierre
          • Declan Moriarty
            ... To clear up some of the issues involved: I think this reply is closest. The parts are Eproms, with a silver label over them wrapped inside metal covers on
            Message 5 of 6 , Jun 16, 2006
            • 0 Attachment
              On Fri, 2006-06-16 at 00:27 +0200, docydoc wrote:
              > @Declan:
              >
              > Claiming to the ideas of what Pieter wrote:
              >
              > Have the eproms been exposed to radioactivity or xray or strong or high
              > frequency electric fields
              > or something similar? This all may lead to failures you were talking about.
              > (I remember erasing some OTP-chips some years ago using xray :-)
              >
              > nmos data retention is given by numerous manufacturers with "at least"
              > 10 years. Nobody knows what happens then.
              > newer cmos last longer. Have not found data retention analysis based on
              > different programming algo but
              > agree with Pieter. Take a look at the microchip site they have had
              > article about data retention and how to get maximum
              > write cycles.


              To clear up some of the issues involved: I think this reply is closest.
              The parts are Eproms, with a silver label over them wrapped inside metal
              covers on a high current Forklift drive Panel. Chassis floats on
              forklifts, for safety reasons. Max voltage is 80V but these are fed from
              a 48V take-off, although the boards see 80V in places.

              /start shaggy dog story
              The story is: The Forklift went on fire; it was got working quickly and
              irresponsibly(they put out the fire, then somebody tried it); The cpu
              card died soon enough; They bought a new card (€1100 or so). That
              failed shortly afterwards. Probably on reccomendation, they swapped the
              wiring loom, which is an absolute bitch of a job as it goes under a 1
              tonne battery compartment. That fixed it (along with a third cpu card)

              /end shaggy dog story

              I got both the cards for repair and find only the eproms are gone. My
              pinpoint is function testing all the rest OK.

              I find it hard to imagine ~20khz switching doing this alone, as many
              other 20 year old eproms from the same company are in my posession, and
              this is not a regular failure mode. The programming line is tied to a 5V
              signal, IIRC on the 27c256. That leaves harmonics of the switching? The
              switching is powerful, btw. About 80V, 80A normal running with anything
              up to 400Amps stall current. That's kilowattage.
              --
              With Best Regards,

              Declan Moriarty.
            • Jaap van Ganswijk
              ... The procedure was I think: pulse and test until the value had changed to zero and then pulse three extra times. The method lead to quite unreliable EPROM s
              Message 6 of 6 , Jun 21, 2006
              • 0 Attachment
                At 2006-06-15 23:27, Pieter Hoeben wrote:
                >Hi,
                >
                >> Declan Moriarty wrote:
                >>I am repairing 2 Boards from the same device with ST 27C256B eproms in
                >>them, and both of the eproms have a form of partial amnesia. Put them in
                >>a programmer, take a checksum, and they return a different figure each
                >>time it is done. This is not a standard failure mode, I might add. They
                >>originally ware programmed with the same program, but different batch
                >>dates
                >>In a buffer editor, they appear to have random bytes 0f 00 and FF added
                >>in the lower portion, although they seem intact higher up. I am left now
                >>looking for a copy of the program intact
                >>Any idea what causes this? This is the second time I have run into this
                >>phenomonon, as another factory had memory chips that lost it in nearly
                >>every machine. I'd _love_ to know what'#s behind it. You can dismiss
                >>poor programming - the source is impeccable.
                >
                >I think it is strange that whole bytes change. I would expect
                >single bits to fail.
                >
                >What may have happened is "fast programming". In the old times
                >eproms needed times like 10 msec up to 50 msec a byte for
                >programming. This is fact charges some internal capacitors.
                >Newer eproms are much faster.
                >
                >Anhd then sombody got the idea: what if we program it for
                >for example 5 msec, and then check if it is ok? If not do
                >it some more. This indeed made programming faster. But
                >may also lead to not fully charged capacitors.

                The procedure was I think: pulse and test until the value
                had changed to zero and then pulse three extra times.

                The method lead to quite unreliable EPROM's sometimes
                and when we wanted to program 'more modern' EPROM's
                reliably we didn't use the manufacturer's algorithm
                but just used an old Intel or NEC algorithm. Took more
                time of course, but saved time debugging EPROM
                errors instead of software errors.

                >This can
                >seriously degrade data retention (should be something like
                >10 years or 100 years, depending on the device).

                We found EPROM's to be very unreliable anyway. We
                developed our own Pronto! programmer around 1988
                but for production purposes we always used new
                EPROMs and re-used old ones only for debugging
                (my) programs in development. Every time we
                erased them (using a Philips face-browning lamp)
                about 5% of them would die (might also be caused
                by the infrared rays heating them up. ;-)

                For production we always used the thorough burning
                procedures I think.

                Greetings,
                Jaap
              Your message has been successfully submitted and would be delivered to recipients shortly.