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.

How Long does the dying Z90/95 system have to do a backup?

Other Parts Discussed in Thread: BQ29330

When the bq20z95 proceeds with a SAFE shut down, pursuant to firing a Chemical Fuse, the chip will no longer have power to keep it going. Yet, in the face of this failure, the designers of the z95 kindly made provision for a swan-song sequence, where the state of the chip is stored:

 

 From: “2.2.1 2nd Level (Permanent) Failure Actions

 

A backup of SBS data and the complete memory map of the bq29330 is stored to data flash.

 

In order for this data storage to be successful, the chip must be kept alive briefly, thanks to an external capacitor on Vdd.

 

Questions:

 

-          How long does the full data storage take to complete?

-          Might this answer suggest a cap bigger than 1uF on the Vdd, in order to do an adequate keep-alive?

 

My estimates suggest that 1uF is rather small for insuring this backup is successful.

On the Z95 data sheet, I see a Mass-erase time” of 200ms for the flash. If I assume a massive write to be about the same, then I have about 400ms to pull this caper off. I am out in the weeds?

 

Anybody have the answer?

 

Thanks,

Michael A. Banak, PE

http://eclectic-engineering.net

 

 

  • Michael,

    In fact the z95 could not rely on that capacitor to do the back up - it relies on the power from the battery.

    The battery power is still available through the BAT pin, even if the fuse is blown.

    The backup takes less time than Mass-erase time, as only less than 50 bytes of data were recorded to the data flash, which includes about ~10 bytes from the AFE memory.

    SimonW

  • Thanks, Simon. I did not realize that the BAT pin was a pathway of power into the Z95. Your timely reply helps me eliminate a pathway of analysis in a tricky debug cycle.

    Most gratefully, Michael