1 2 Previous Next 16 Replies Latest reply on Nov 10, 2015 8:05 PM by AnKa_1206521

    Monitoring VDDD without pin use

      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?





        • 1. Re: Monitoring VDDD without pin use

          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.

          • 2. Re: Monitoring VDDD without pin use

            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.





            • 3. Re: Monitoring VDDD without pin use

              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.

              • 4. Re: Monitoring VDDD without pin use

                Thanks for checking!


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



                • 5. Re: Monitoring VDDD without pin use

                  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.

                  • 6. Re: Monitoring VDDD without pin use



                    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.



                    • 7. Re: Monitoring VDDD without pin use

                      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.

                      • 8. Re: Monitoring VDDD without pin use

                        :) 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.

                        • 9. Re: Monitoring VDDD without pin use

                          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).

                          • 10. Re: Monitoring VDDD without pin use

                            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.

                            • 11. Re: Monitoring VDDD without pin use

                              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.





                              • 12. Re: Monitoring VDDD without pin use



                                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?







                                • 13. Re: Monitoring VDDD without pin use

                                  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.

                                  • 14. Re: Monitoring VDDD without pin use

                                    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 :)



                                    1 2 Previous Next