HP-15C LE : Workaround for the high current spike
#1

Additional bypassing capacitor of 100uF will reduce the high current spike which may cause "Pr Error".

Current draw at Power-on (10mA/div, 400us/div)

"Workaround for the high current spike "

Regards,

Lyuka

#2

Quote:
Additional bypassing capacitor of 100uF will reduce the high current spike which may cause "Pr Error".


Have you actually measured the VDDCORE voltage rail depression
which coincides with that transient? Reason being is the level
of bypass Atmel calls for is fairly heavy and I believe HP
followed their guidelines relatively closely -- well best I can
puzzle out through opaque black solder mask.

What you may be seeing in the overall main inrush at power on
also includes the LCD charge pump and its output bypass which
is discharged at power on. Atmel had added series resistance
to the LCD rail bypass possibly to reduce this turn-on
transient. Note the VDDCORE rail is downstream from VDDIO1,
is fed by the internal regulator, and has its own bypass so it
should be relatively well decoupled from the main VDDIO1
transient. But admittedly I haven't confirmed the effective
isolation via measurement.

#3

Interesting!
Did you measure the standby current? Any increase due to leakage of that capacitor?

Regards,
Bob

#4

Hi uhmgawa,

The decoupling around the MCU seems good, but it's not the point.
Though it's good for stable power supply, the total amount of the bypassing capacitance is not enough to eliminate the supply voltage drop by the internal resistance of the batteries for 40mA-40us spike.

To make the things worse, it's not the in-rush current, in other words, this spike occurs at every any key presses.

As previously mentioned by Seth Morabito at this thread, the battery voltage depression occurs by high current draw (20mA or so) and the internal resistance rises enough to drop the voltage below 2.0V at the current spike. The high current draw condition occurs at every key press or at calculator is "running", and the voltage recovery time of the CR2032 battery is quite long after such heavy load.

By my quick test, the "Pr-Err" happens after battery voltage drop less than 1.8V or so, at that voltage calculator will shutdown.

Regards,

Lyuka

#5

Hi Bob,

The leakage current of a ceramic capacitor is negligible (for most applications).

The standby current is less than 0.05mA by my coarse measure. 0.047mA by Katie's measurement.

Regards,

Lyuka

#6

You can get 100 microfarad ceramics that small?!

#7

You can get 100u/6.3V/X5R/3216 metric size capacitor(s) at,

TDK, C3216X5R0J107M, 100u/6.3V/X5R/3216 metric

or

TaiyoYuden, JMK316BJ107ML-T, 100u/6.3V/X5R/3216 metric


Edited: 11 Jan 2012, 11:22 p.m.

#8

Quote:
To make the things worse, it's not the in-rush current, in other words, this spike occurs at every any key presses.

I see. That's quite interesting as I'd misunderstood this
to be a power-on transient.

In that case it seems whatever power conservation profile is
in use may actually be disabling power domains in the sam7.
Otherwise I'm not sure what would likely be causing such a
wakeup transient upon any key press. Atmel doesn't specify
instantaneous current draw for the sam7 but the rather heavy
bypass usage would be consistent with attempting to tame transients
upon wakeup from a power domain disabled to active state.

#9

Quote:
You can get 100u/6.3V/X5R/3216 metric size capacitor(s) at..

Alternately the added bulk bypass for the 3V0 rail (VDDIO1 / VDDLCD)
can be distributed among C16, C17, C20, and C21. VDDCORE is
decoupled by C11 and C12.

Bypassing local to the sam7 would also factor out the impedance
of the 3V0 supply trace stretching across the board -- the
board is only a two layer design without benefit of a power
and ground plane. Actually getting this on two layers is a
respectable effort given all vias had to live outside of the
tactile dome lands on the opposite side. A concession to
simplified (inexpensive) board routing is also quite likely how
the 15c le ended up with legged domes vs. the smoother round domes
found in the original voyager layout.

#10

Quote:
To make the things worse, it's not the in-rush current, in other words, this spike occurs at every any key presses.

...

The high current draw condition occurs at every key press or at calculator is "running", and the voltage recovery time of the CR2032 battery is quite long after such heavy load.


This is a combination of two effects: The CPU core is powered down between key presses to conserve power, just the LCD is powered and some pull-up resistors for the keyboard. On a key press, the device is woken-up. Here, something has been screwed up in that the processor goes to full power (and stays there as long as the key is down.) The latter should be responsible for the stress on the coin cells.

I'd like to see the same measurements for the 12C+ (same hardware, different firmware), an original 20b or 30b, and, of course, for WP 34S on either hardware.

#11

Hi Marcus,

I really think that power management of a system which emulating an old hardware is a kind of most difficult, at least confusing thing to do.

Quote:
I'd like to see the same measurements for the 12C+ (same hardware, different firmware), an original 20b or 30b, and, of course, for WP 34S on either hardware.

So am I. Unfortunately I have non of the calculators you have mentioned above.

Lyuka

#12

Lyuka, you're one cool dude :-)

cheers,

hpnut in Malaysia

#13

Thanks hpnut :-)

#14

Quote:
This is a combination of two effects: The CPU core is powered down between key presses to conserve power, just the LCD is powered and some pull-up resistors for the keyboard. On a key press, the device is woken-up. Here, something has been screwed up in that the processor goes to full power (and stays there as long as the key is down.) The latter should be responsible for the stress on the coin cells.

The high sustained current draw at wakeup is a potentially
missed power conservation optimization in the emulator design.
The ~40us transients seen at beginning and end of this interval,
which the additional bypass is attempting to suppress,
appear to be a chip/hardware characteristic as this exceeds the
sustained current draw specified for the device.

Profiling the current draw for the WP 34S would probably be
the most useful as it would be possible to correlate the
current draw to known activity in the sam7.

#15

Thanks for the info.

Got any idea what the DC internal resistance is? i.e. could I use these for long time-constant circuits with a 1 meg or even 10 meg resistor and still get tau = RC of 100 seconds or more?



Possibly Related Threads…
Thread Author Replies Views Last Post
  Programming workaround for "prepend" HP PRIME Marek Russ 4 1,982 11-29-2013, 05:46 AM
Last Post: Marek Russ
  OT - A lucky find - Busicom Handy-LE LE-120A Cristian Arezzini 2 1,782 09-26-2013, 04:43 AM
Last Post: Cristian Arezzini
  Low power warning for HP-15C LE and batteries Nick_S 1 1,380 09-16-2013, 09:34 AM
Last Post: Hans Brueggemann
  HP 15C-LE replacement still available? Borja 16 5,381 08-22-2013, 11:16 AM
Last Post: Michael de Estrada
  A workaround for the inefficient SUBST command peacecalc 3 1,382 07-03-2013, 05:17 PM
Last Post: Gilles Carpentier
  JTAG on HP-12C and HP-15C LE Ingo 5 2,385 07-01-2013, 06:37 PM
Last Post: Paul Dale
  HP 15C LE extremums Richard Berler 29 8,542 05-20-2013, 03:26 PM
Last Post: Dieter
  HP-35 and HP-65 Current Requirements Dan Lewis 0 915 03-05-2013, 12:11 AM
Last Post: Dan Lewis
  New 15C LE bug? Paul Dale 3 1,760 02-05-2013, 09:27 PM
Last Post: Mike Morrow
  HP 15C LE, Program Display Format Control Uli 4 2,290 01-20-2013, 01:22 AM
Last Post: Ethan Conner

Forum Jump: