Monitoring VDDD without pin use

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am short on available pins using the PRoC BLE module.

   

Is there a way to monitor my battery supply voltage without using an analog input pin like I can do on my PIC projects.

   

I see there is a 1.024 internal reference but do not see an obvious way to read it with respect to VDDD. Is there a way?

   

On my PIC projects I can do this so that, if I assume the reference is exactly 1.024, and if I get a reading of it with respect to VDDD, it is a simple matter to calculate current battery voltage and no pin is lost doing this.

   

If there is, is there a way to double scale the Vref before I read it with respect to VDDD?

   

Thanks,

   

Dale

0 Likes
16 Replies
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One way would be to use the Global Signal component in the

   

system group of components and use the PWRInt selection.

   

You use APIs to set its threshold. Would that suffice ?

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

That looks like I can get by with it, although I have been hibernating at 3.3v with my PICs.

   

Too bad, that was a neat PIC trick that gave decent resolution with the Vref scaling for a single cell lithium device.

   

Thanks,

   

Dale

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Turns out in a regular PSOC 4 you can get access to a Vdd Vref to feed to A/D.

   

But no Vref component (user accessible) is there for PROC that I could see.

   

You can under API control change the Vref the A/D uses, but can't get at it to

   

feed to the A/D for measurement.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Thanks for checking!

   

1st reason to switch to PSoC, but not compelling enough list yet.

   

Dale

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I was the Freescale 8 bit specialist in New England for awhile. Also worked

   

with uChip.

   

 

   

I have done several designs in PSOC 1, am working on porting some stuff

   

to PSOC 3 / 5LP.

   

 

   

Making comparisons between manufacturers is tedious and difficult I have found.

   

Tables are a start but never tell the whole story.

   

 

   

What drew me to PSOC was analog and digital routeability. And more analog

   

resources than a couple of OpAmps or Comparators as found in other manufacturers.

   

And in the higher end family the DFB engine, more than just a MAC, many uses.

   

And DMA helped, create background processes I did not have to service. I recall I was

   

very enthusiastic when NEC did the V25, 20+ years ago, but abandoned it. micro coded

   

background processes and busses to support them. But we have PSOC now.

   

 

   

Tools are a consideration, I wrote code on a PDP8 to test ICs, paper tape, and worked

   

with Teradyne whose docs so bad I had to write test vectors to figure out how their CPU

   

worked. Ugh. So I like good tools, but less willing these days to work with poor hardware

   

and little or no configurability.

   

 

   

Enjoy PSOC, not perfection, but the crew keeps making regular improvements in both tools

   

and HW. Buts that is what our children are for, to make things better....:)

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Dana,

   

That is quite the career! I have only done a dozen or so PIC projects (but I did design and build the Lazair when I was younger and more recently the eLazair).

   

It is nice to know a little about that person out there in cyberland that has been helping me.

   

Dale

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

That is an awesome accomplishment. I looked at the Wiki site. You clearly had a lot

   

of originality and success.

   

 

   

I had a birthday present years ago and did a glider ride, had one great experience. Just north

   

of Bay Area, only downside was it was hot riding in front seat with limited air ventilation.

   

I tried flying it just a little, really challenging being at the tip of a spear trying to navigate.

   

Reminded me of when I qualified on SSN583 at the planes, flying a sub underwater is pretty

   

much same as flying in liquid, air. I have flown (as rider and newbee) and sky dived out of

   

small Cessna and always enjoyed the "feel" of real flying. Even the feel of being close to

   

front of commercial airliner reminded me of turns on the sub, corkscrew effect. And the

   

effect of turning a 5 MW reactor into a 150% back bell to stop the boat, some things one

   

never forgets.

   

 

   

A lake I am quite familiar with had, up until last year, a fly in every August, and all kinds of

   

experimental sea planes would come. I used to boat around the planes and drool.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

🙂 I have a US record in Standard Class gliders with a 1000 mile flight.  Looks like we would have a lot of experiences to share over  a few beers sometime!

   

To summarize the thread:

   

On PRoCs, if the only thing you want to do is to protect your battery by going to a lower power mode at a certain voltage, you can do it without a dedicated PRoC I/O pin as Dana has shown.

   

BUT, if you want to send the actual battery voltage out on BLE you need to use a pin.

0 Likes
Anonymous
Not applicable

As a final summary here, confirmed by a MyCase:

   


1. There is no way, on PRoC CYBLE-022001 module, of reading battery voltage and sending it out BLE connection unless you waste an I/O (of the few exposed) and waste power thru a voltage divider to bring battery voltage to <1.024v before routing it to that exposed pin.

   

2. The vRef pin is NOT routed, on the module PCB, to an unexposed I/O pin. Why, this would let us read battery voltage without either waste of point #1.

   

3. There is no way to use the API to internally route the vRef to the analog MUX on the PRoC chip. Why not, this would ALWAYS save the wastes of Point #1?

   

For a chip whose life is almost always powered by battery, it sure appears difficult and wasteful to monitor that battery voltage.

   

The 'near' future sees only a slight improvement:

   

As yet unreleased module CYBLE-024008-00 has 42 pins with 25 GPIOS exposed (including vRef).
 

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

No way to dual purpose a pin, like SWD assigned pin, use reg writes

   

to disconnect SWD and connect to Vdd R divider (pin) for reading ?

   

 

   

Note the R divider would have to occur on chip thru internal ratio accurate R

   

network, or sw cap + integrator approach. Or external, either way power

   

gets dissipated.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

I have the dedicated pin available (my last one).  I think I'll try a 1M/220K divider and run a simple calibration routine on a known input voltage.  Then save the calibration permanently each time I program one of my boards.  That is maybe 4ua if it works, which nearly triples my OFF current, oh well.

   

Thanks,

   

Dale

0 Likes
Anonymous
Not applicable

Dana,

   

I was still hoping to use your Global Signal method of generating an interrupt at 3.3v even though I should be able to monitor the voltage on my analog in pin while I have code running.

   

Problem is I am using a periodic WDT0 during my BLE advertising state at 1296ms rate to wake up from Deep Sleep every 50ms to take care of reading sensors (and battery volts 🙂 and setting outputs based on sensor values, then going back to deep sleep.  I don't actually have any interrupt code in the WDT0 (it wakes from deep sleep every 50 ms by just enabling the periodic WDT0) but the fact that I use WDT0 (during advertising only) is preventing me from having a Global Signal with an interrupt using WDT's for your suggestion, at least according to this build error:

   

Clock Model Error: (WDT interrupt generated by PSoC Creator will be overwritten by the 'LowBat_ISR' ISR handler of the 'LowBatINT' component and the user will not be able to attach his functions to the individual WDT interrupts using callbacks. Either remove the component or change the interrupt generation option to 'Implementation by user').

   

I am having a little trouble tracking down 'Implementation by user'.

   

Can you think of someway I could set this up so it will build and such that I only use Global Signal interrupt after I stop checking sensors during advertising (and thereby stop using WDT0) due to inactivity of sensors?

   

EDIT:  What is interesting to me is that the available Global Signal method of tripping at a specific voltage, selectable from a table, implies that Cypress is actually able to read an analog value for the battery voltage using this method (no wasted pins and no wasted power).  Why then can't we just have access to that value?

   

 

   

Thanks,

   

Dale

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The architecture TRM does not describe how the LVD is implemented, but I

   

would posit its a comparator  with a programmable reference, eg. not an A/D

   

process. You could chk this by filing a CASE.

   

 

   

Either remove the component or change the interrupt generation option to 'Implementation by user').

   

 

   

I think a CASE is going to be necessary to get factory to clear up if there is a placeholder

   

available or does one have to diddle the vector table to get a user ISR going.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Thanks that sounds feasible but more complex that if they just had the VREF going to analog MUX.

   

I couldn't find 'implementation by user' in either of the components properties or component datasheet.

   

I'll make a case on some of this after I am able to program my darn PRoC.

   

You are up early/late 🙂

   

Dale

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The early/late thing is a sickness of a brain fried by hi tech....:)

   

 

   

Early due to father a lobsterman, on the boat out of the harbor at sunrise.

   

 

   

Regards, Dana.

0 Likes
AnKa_1206521
Level 2
Level 2
First like received First like given

Hi Dale,

   

I don't know if you've found a resolution to this:

   

Clock Model Error: (WDT interrupt generated by PSoC Creator will be overwritten by the 'LowBat_ISR' ISR handler of the 'LowBatINT' component and the user will not be able to attach his functions to the individual WDT interrupts using callbacks. Either remove the component or change the interrupt generation option to 'Implementation by user').

   

I am having a little trouble tracking down 'Implementation by user'.

   

I came across that error (and subsequently this thread) today and after some hunting about discovered the hint is the "clock model error" part, if you go into your .cydwr file -> clocks tabs -> edit clocks down the bottom RHS you'll see an option to set the Timer (WDT) ISR to "User provided".

   

Cheers

   

Anthony

0 Likes