Connect with us

mystery software (?) death

Discussion in 'Electronic Basics' started by [email protected], Mar 22, 2007.

Scroll to continue with content
  1. Guest

    hello, I was wondering if anyone had ever encountered something like
    my latest joy.

    summary:
    unit stops working, yet when you read in the program and e2prom space,
    the data looks fine and when reprogrammed, the chips (and circuit)
    work fine

    details:
    we have a circuit using a PIC12F629 with softwareA. been using it for
    years. no problem

    now, same circuit, new softwareB.

    does the same basic thing as A. we developed it, tested it debugged
    it. sent it out.

    now (after about 80 of the units were assembled and 40 shipped out).
    we start seeing these failures.

    example:
    a unit assembled and burned in here at the plant for less than 1.5
    hours.. found dead

    2 units, sent in the field, worked.. a day, a week.. then died

    so we recalled everything and set 10 units, non-encapsulated, to run
    in the lab

    after about 2.5 days, one died. being unencapsulated, we were able to
    take the chip and read it using our programmer (Promate II).

    my original suspicion had been that the E2prom was getting scrambled.
    something I had encountered in another project and which could have
    resulted in a situation where the program functions, the chip pins are
    fine.. but the orders which were in E2prom are now gibberish and so
    the unit appears to be dead.

    but, when I read this chip. everything was perfect. software
    identical to what was programmed in. OSCAL look healthy. E2prom as
    was programmed in

    tried a different in the circuit.. circuit worked fine. tried the
    'bad' chip in the circuit again.. dead. reprogrammed the 'bad' chip
    (to see if maybe pins were missbehaving)... works fine; still working
    fine after.. roughly 2 days.

    no others of my labrats have died (so they have been on for ~~4.5
    days)

    anyone with ideas... pretty please!
     
  2. Strange indeed. Two possibilities comes to my mind:
    - The programmer. Does the programmer overstretched the units somehow? Does
    it use the correct programming sequence? Especially when a 629 has been
    programmed with the MCLR as an input pin, the correct sequence of VCC and
    VPP is important to make sure the chip comes in the right programming state.
    - Handling. ESD sometimes has strange effects on flash programmed devices.

    petrus bitbyter
     
  3. Jamie

    Jamie Guest

    Yes, have any inductive or high energy near it?
     
  4. Guest

    thank you to everyone who threw ideas out there!

    looks like the reason the unit seemed to 'die' was that that version
    of code wasn't prepared to deal with garbage in the one byte I write
    to. my very bad. I can make so that units keep working when garbage
    drops in.. but there will be interference with the product function..
    such that if it happens more than once, our clients are going to have
    fits

    so the question is redefined as: how can I avoid garbage getting in?

    assuming (and this is an assumption) that the garbage entered by way
    of a weird power problem (brown out..?) at a bad moment (say in the
    midst of a write)
    1) I have _BODEN_ON & _PWRTE_ON.. isn't that supposed to make brown
    out a non-fatal thing?
    2) is it possible for the weird power problem to cause garbage to
    appear in a location other than that which I was trying to write to?
    this would be extremely scary..
    3) if in user memory I save the data and address I was trying to
    write. could I check on every 'processor reset' if there was a write
    err... and would data in user space be safe after such?
    4) anyone have any tricks to safeguard operation? in this case there
    is only 1 byte I ever write to, but the next project I have to do
    would have up to 4 bytes that would get written to regularly
     
  5. Guest

    thank you to everyone who threw ideas out there!

    looks like the reason the unit seemed to 'die' was that that version
    of code wasn't prepared to deal with garbage in the one byte I write
    to. my very bad. I can make so that units keep working when garbage
    drops in.. but there will be interference with the product function..
    such that if it happens more than once, our clients are going to have
    fits

    so the question is redefined as: how can I avoid garbage getting in?

    assuming (and this is an assumption) that the garbage entered by way
    of a weird power problem (brown out..?) at a bad moment (say in the
    midst of a write)
    1) I have _BODEN_ON & _PWRTE_ON.. isn't that supposed to make brown
    out a non-fatal thing?
    2) is it possible for the weird power problem to cause garbage to
    appear in a location other than that which I was trying to write to?
    this would be extremely scary..
    3) if in user memory I save the data and address I was trying to
    write. could I check on every 'processor reset' if there was a write
    err... and would data in user space be safe after such?
    4) anyone have any tricks to safeguard operation? in this case there
    is only 1 byte I ever write to, but the next project I have to do
    would have up to 4 bytes that would get written to regularly
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-