• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 804 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PGA450-Q1: EEPROM wiped on power cycling

Armon Chojnacki
Prodigy 20 points
Part Number: PGA450-Q1

To whom this may concern,

We are facing some issues regarding EEPROM retention in the pga450 in our solution. It would appear that after power cycling the pga450 a certain number of times the EEPROM Values [11:30] get wiped and are null; preventing any further measurement operation to be carried out using the EEPROM as configuration. It appears that the module behaves nominally, turning on, receiving the UART command to take a measurement and returning correct values; until after a seemingly random number of power cycles later where the EEPROM[11:30] is 0x00. We are using a custom algorithm to calculate the thresholds used by the pga450, however there doesn't seem to be any immediately apparent source of memory overflowing, and we do not write to EEPROM or have any function to do so in our 8051W source code. Please let me know if a similar issue has arisen in the past and if there is an existing solution. Thanks for your time and support, I would be willing to share the project source code in a private conversation if you believe it may assist you in identifying the source of our issue.

Regards
Armon Chojnacki

  • 0
    TI__Mastermind 27950 points
    Hi Armon,

    Our immediate thought is that the EEPROM has been weakly/insufficiently programmed if the values become partially nullified.

    1) How many device have experienced this failure?
    2) Do the effected EEPROM values always reset to ‘0x00’, or are do some bits randomly retain their values?
    3) What is your step-by-step detailed procedure or code of programming the EEPROM?

    As noted in the PGA450-Q1 datasheet section 7.3.15.3.2 Programming EEPROM Through the 8051W and SPI, step 3 requires the user to wait at least 70ms to allow the EEPROM memory to fully apply internally. Is it possible that the your EE program routine is violating this timing requirement, and interrupting the device’s internal EEPROM programming by communicating to device (non-EE_STATUS poll) before 70ms has expired?
    Here is the section snippet from the datasheet describing the required routine:
    7.3.15.3.2 Programming EEPROM Through the 8051W and SPI
    The following is the EEPROM memory programming procedure:
    1. Write data to EEPROM cache – Use the 8051W MOVX assembly instruction to place data in external memory addresses 0x0400 through 0x041F.
    2. Write a 1 to the WRITE bit in the EE_CTRL register.
    3. Continuously poll the EE_STATUS bit in EE_CTRL register for the programming status. The EEPROM programming requires 70 ms to complete.

    Typically, for a device EEPROM retention failure, either a single cell or row will become zero, but not the entire or large portion of the EEPROM memory space.

    Is it possible that a device reset is forcing the look-ahead registers to clear before they are burned/programmed to the EEPROM memory space?
    Does your mass programming routine involve a complete power-down, wait, and power-up of the device after programming the EEPROM to check if the EEPROM values were truly retained? It is best to execute this step with a program that does no programming to rule out inadvertent programming issues.
  • 0 in reply to Akeem Whitehead
    Prodigy 20 points

    Hi Akeem,

    Recently we had manufacturing send us 100 of our boards for an internal field trial, out of these we are probably experienced this issue with 20 of them. The issue seems to be sporadic, however I have had most results reproducing the conditions by power cycling the PGA450 on a scale of ~1000 times. This would be nominally how we would treat the PGA450 on our board as we use an MCU for most of the logic/control and would like to reduce the overall current consumption of the device considering we are using a battery as a power source.
    The values always seem to be set to 0x00 and it always seem to be the subset EEPROM[11:30] which is accessed (read only) before triggering the burst to get the esfr configuration values for the band-pass filter as in the sample firmware (command 5()) provided by TI on the PGA450. 
    For programming the devices would be loaded with a custom firmware which retains the power to the PGA450 high so that the programming can be carried out. A custom spi cable is connected from the TI-GER board to the device under testing (according to the datasheet sldu019b) and the GUI is loaded up. The PGA450 is placed in MicroReset mode, the EEPROM values are verify as provided from manufacturer (0xAA) and a grid is recalled containing the configuration settings of our system; finally the EEPROM is programmed. The PGA450 is placed in MicroActive mode, the spi cable is removed and then the power is removed. If OTP programming was required it would be performed prior to flashing the EEPROM, and the VDD-VOTP jumper would be applied prior to programming and removed prior to placing the PGA450 in MicroActive mode.

    Any code which may have been used to write to EEPROM has been removed from our firmware on the 8051W yet we still see the same behavior, I had believed we may have been facing an issue with faulty code execution as we had failed to meet the prerequisite 1V/ms ramp-down time as specified in the PGA450 datasheet, however there is no longer any functions in the firmware which would allow for the EEPROM to be written to in the case of stack pointer overflow. I am willing to share schematics and firmware if you believe it would help assess the issue we are facing.

    Regards
    Armon Chojnacki

  • 0 in reply to Armon Chojnacki
    TI__Mastermind 27950 points
    Hi Armon,
    Your programming flow seems correct based on your description.
    After removing power from the device once you have initially programmed the EEPROM, do you wait, then apply power again to check that the EEPROM has retained after power cycle?

    If you'd like to send me your schematic and programming code, I can review them to ensure there are no violations. You can send me these files as attachments in a private message if you do not want to make them public on E2E.