I'm using an AS6C1008 SRAM chip, and I'm having an odd issue with it. The voltage supply going to this chip is created from a stiff 5V supply (VDD) and a 3V backup battery (CR2032), diode or-ed together (calling this net VCC). During normal operation (powered by VDD), measuring with an oscilloscope and also verifying with a multimeter, I see the voltage supply on VCC raise up usually to about 5.6V. Sometimes, I have seen voltages as high as 5.8V. This only occurs when /CS1 is at VCC for a long enough period of time - as /CS1 is pulled to GND, the VCC supply will discharge, eventually reaching to VDD minus a small diode drop, as would be expected. Once /CS1 is returned to VCC and the SRAM is no longer enabled, VCC will charge back up to ~5.6V.

And to add to the weirdness, using the similar but smaller AS6C62256 SRAM chip doesn't exhibit this behavior. VCC is equal to VDD minus a small diode drop as would be expected.


Schematic of battery-backed RAM

Using a 62256 (28-pin device) in place of the 1008 (32-pin device) works because the supply pin is tied to VCC in either case. (Originally, A15 and A16 went to actual address lines, but I ended up tying them to GND for testing so it mimics a 62256)

Definitions and Parts

VDD: 5V supply, VCC: diode-ored voltage from VDD and battery. All address/control pins on the SRAM (IC5) are referenced to VDD, except /CS1 and CS2 which are referenced to VCC. /CS1 is called CE# and CS2 is called CE2 in the datasheet for the AS6C1008.

Q1 is a 2N3904, D1-D3 are BAT85 Schottky diodes, CB is a 22uF alel, C2 is a 100nF ceramic bypass cap (both are located very close to the SRAM chip). /RESET net is GND when VDD is off, otherwise it's ~VDD (for the purposes of this operation, /RESET is always logic HIGH)


When a specific address range is accessed (A13, A14, etc.; max clock speed is ~4MHz), the 74HC139 will pull the Y1 output low. /RESET is HIGH, so current flows from collector to emitter of Q1, pulling /CS1 LOW. When the specific address range is not being accessed, Y1 is HIGH, and /CS1 is HIGH. CS2 is always set to VCC, allowing CE# to control access to the RAM (and maintain low standby current when VDD is removed).

I cannot change the VDD supply or the clock speed, these lines are external to my board.

Scope Traces

Scope #1

Scope #2

Ch1 (yellow): VDD, Ch2 (light blue): /CS1, Ch3 (purple): VCC, Ch4 (dark blue): Y1 output of 74HC139. These traces are measured with the reference directly on the GND pin of the SRAM chip, but the GND reference is the same everywhere on the PCB with thick traces/planes.

In the first capture, VCC starts at around 5.6V. At the trigger (set at 4ms from left side of capture) the SRAM begins to be accessed by pulling /CS1 LOW. As this addressing continues, VCC keeps discharging down, until eventually it reaches VDD (convergence is off-screen).

The second capture is zoomed in at the first pulses of /CS1. You can see that after a ~0.5us pulse of /CS1, the voltage returns to VDD, not the higher VCC, for about 1us before returning to 5.6V. As time goes on, /CS1 begins to match Y1 output because VCC lowers to ~VDD.

Scope #3

EDIT: Ch1 (yellow) is /WE and Ch3 (purple) is /OE.

Attempted (and Failed) Solutions and/or Troubleshooting Steps

Doing the following barely impacted the increased voltage, if at all:

  • Tried three separate 1008 chips
  • Changed values of R3, R4, and R5 (100k, 10k, 10k; 100k, 33k, 33k; etc.)
  • Removed R1 completely to remove the battery from the equation
  • Swapped out the BAT85s for 1N4148s
  • Removed CB and C2
  • Added series resistance of about 50Ω to the SRAM supply
  • Added 1Mohm across VCC to GND
  • Tied pin 1 of the AS6C1008 (which is NC) to GND, VCC, left floating (it was a shot in the dark)

Solutions That Worked (But I Don't Want)

  • Small series resistance + 5.1V Zener diode in parallel with supply pins, but this greatly increases (~30x) the current out of the backup battery when VDD is removed
  • Adding a 100k across VCC to GND fixes it, but as with the zener, causes the battery to drain faster.
  • As mentioned, replacing the AS6C1008 with an AS6C62256 fixes the issue, but I also only get 25% of the available SRAM memory
  • The AS6C6264 also doesn't exhibit this issue either

So... it kind of seems like I somehow made an unintentional charge pump. But I'm not sure how, or why, especially that it only affects the 1008 and not the 62256 or 6264. Does anyone have any ideas of how to mitigate this without sacrificing battery life from the backup battery?

EDIT: Potential Solution

I decided to add another NPN that will turn on during normal operation (/RESET is at VDD) to load VCC with a 10k resistor. When /RESET is low, Q2 shuts off and allows minimal leakage current (measured ~0.5uA). This way, I can put VCC at the expected safe value, while not impacting battery life with a constant load. This doesn't tell me why VCC is raising up above VDD in the first place without a load, but this does seem to fix the symptoms.

Originally I tried tying R6 to VDD instead, but there is some leakage current through D1 that allows VCC to charge up the bulk capacitance on VDD (not shown in schematic) to about 0.5V. This will bias Q2 enough to allow some current through R7 (measured ~10uA).

Modified schematic

EDIT: Alliance Repsonse

Thankfully, Alliance actually got back to me. It appears that the 1008 SRAM chips have an extra ESD protection diode included from the input to VCC (Dp in the schematic). The other series of chips do not have these diodes, only using the one from the input to GND (Dn).

Alliance reference

So it looks like the input noise is being rectified into the supply, and not being discharged fast enough. I think I will stick with the NPN circuit I've added to lightly load the supply while power is on to keep VCC at proper levels. Shortening/thickening the traces isn't extremely feasible, and adding series resistances to dampen the noise would greatly increase the BOM count, and I probably don't have enough room for them anyway.

  • \$\begingroup\$ Do you have a trace showing the other signals, RD, WR? The high voltage could come from them. Differences in the ESD structures between the two types of RAM may have different effects. RMS is not the correct setting to show the upper level - it will not be the same as DC with some signals. Rigol calls the correct setting Vtop, That will ignore short peaks but give the voltage of the flat top. \$\endgroup\$ Apr 21, 2022 at 2:51
  • \$\begingroup\$ I will take a SWAG and say: Try adding some resistance maybe 500 ohm between VSS and VCC and see what happens. If it drops dramatically you have noise being generated in the chip raising its voltage. I saw this happen many years ago, and it repeated from board to board. It is also possible some of the lines are picking up noise and the protection diodes in the are doing what Diodes do rectifying the voltage. This is a test, not a solution. \$\endgroup\$
    – Gil
    Apr 21, 2022 at 3:00
  • \$\begingroup\$ @KevinWhite I added traces in the post. They do ring a bit but this also might be measurement noise, not sure. As for the voltage measurement of 5.6V, I wasn't relying on the RMS measurement but the actual level on the scope - also confirmed during steady-state with a voltmeter. Even if it's not exactly 5.6V, it's still very much above the 5V of the DC supply. \$\endgroup\$
    – Nick U.
    Apr 21, 2022 at 3:15
  • \$\begingroup\$ @Gil I added 1k, and it indeed dropped to a normal level (~200mV drop across diode). Unfortunately this isn't a solution as you say because it'll drain the battery quite quickly :( I suspected it could be something with the protection diodes, but I'm not too sure how to proceed. \$\endgroup\$
    – Nick U.
    Apr 21, 2022 at 3:19
  • 1
    \$\begingroup\$ @Gil Unfortunately I don't feel comfortable doing this, running over the max rating of 5.5V. I did reach out to Alliance to ask them about it, I am waiting their response. My application doesn't really benefit from a rechargeable battery, and putting a 100K on the terminal will drop the battery life too low. 1M might be ok though, not sure if that'll be enough to discharge down to the proper voltage. I'll attempt later. \$\endgroup\$
    – Nick U.
    Apr 21, 2022 at 4:02

1 Answer 1


I agree with @Kevin White 's implication that the ESD structures in the SRAM are helping you create an impromptu boost converter. I note that there's some decent ringing on the /WE and /OE traces, and if it's real (and not measurement noise as has been mentioned) then that could be where the excess voltage on the Vcc node is coming from.

internal ESD protection pic for reference: ESD diodes inside and outside the chip


To mitigate that ringing would be an adventure, perhaps PCB layout to minimise inductance, or series resistors to dampen the oscillation, or if you're driving this with some configurable GPIO maybe you can set a register to reduce the drive strength.

As a solution I like your /RESET bleed resistor, and humbly also present my own: use a P channel FET to directly attach the Vcc node to the Vdd node during runtime : Sad digikey scheme-it drawing

(The gate of Q1 can be attached to Vdd or /RESET as is required) Excess energy at the Vcc node will flow back into the Vdd node so there should be little difference between the two. One thing I don't like about this design is the pull up resistor R1, which will tie battery voltage to the gate of Q2 and drain of Q1 while on standby - those transistors will have to be selected first and foremost for gate and drain-source leakage. I am also concerned about the transition from run to standby, there could be a flow of energy from the battery to Vdd before Q2 shuts off properly.

  • \$\begingroup\$ Oh that's a neat idea! Thanks for your insight. I think I'm convinced it's those protection diodes. I'm trying to keep the number of unique parts as low as possible, and keep the cost as low as possible, which is why I went with this 2N3904-based solution because I already use those parts elsewhere. So far it seems to be working well - no impact to performance, and the battery drainage is only 2.5uA total. Alliance has also contacted me again, said they are looking into it. \$\endgroup\$
    – Nick U.
    Apr 24, 2022 at 0:11
  • \$\begingroup\$ I can understand that. Originally I wanted to suggest this as a comment but my rep is too low, so I went through the effort of making it an answer. One other thing occurs to me: if the ringing is real you may have issues getting this past RF compliance testing - if that's in the future for this build. \$\endgroup\$
    – Bryan
    Apr 24, 2022 at 20:08
  • \$\begingroup\$ Nope, just a hobby project :) Glad I don't have to worry about any kind of FCC requirements. I'd probably give up if that were the case haha \$\endgroup\$
    – Nick U.
    Apr 25, 2022 at 0:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.