Pwrstat

  1. Pwrstatd
  2. Pwrstation
  3. Pwrstation
  4. Pwrstat Lost Communication
  5. Pwrstat
  6. Pwrstation Company Profile

This section covers configuration and running debugger using several methods:

  • from Eclipse

  • from Command Line

  • using idf.py debug targets.

. Pwrstat displays incorrect power supply status information for the HP 800W/900W Gold AC Power Input Module and the HP Server RPS Backplane Kit. An intermittent virtual CD disconnection occurs during a system reboot. Another alternative is using NUT (the Network UPS Tools).It talks to pretty much any UPS brand out there, presents a network interface, and you can run the client side on your hosts to shut them down gracefully when the power goes out.

Eclipse¶

Note

It is recommended to first check if debugger works using idf.py debug targets or from Command Line and then move to using Eclipse.

Debugging functionality is provided out of box in standard Eclipse installation. Another option is to use pluggins like “GDB Hardware Debugging” plugin. We have found this plugin quite convenient and decided to use throughout this guide.

To begin with, install “GDB Hardware Debugging” plugin by opening Eclipse and going to Help > Install New Software.

Once installation is complete, configure debugging session following steps below. Please note that some of configuration parameters are generic and some are project specific. This will be shown below by configuring debugging for “blink” example project. If not done already, add this project to Eclipse workspace following guidance in section Build and Flash with Eclipse IDE. The source of get-started/blink application is available in examples directory of ESP-IDF repository.

  1. In Eclipse go to Run > Debug Configuration. A new window will open. In the window’s left pane double click “GDB Hardware Debugging” (or select “GDB Hardware Debugging” and press the “New” button) to create a new configuration.

  2. In a form that will show up on the right, enter the “Name:” of this configuration, e.g. “Blink checking”.

  3. On the “Main” tab below, under “Project:”, press “Browse” button and select the “blink” project.

  4. In next line “C/C++ Application:” press “Browse” button and select “blink.elf” file. If “blink.elf” is not there, then likely this project has not been build yet. See Build and Flash with Eclipse IDE how to do it.

  5. Finally, under “Build (if required) before launching” click “Disable auto build”.

    A sample window with settings entered in points 1 - 5 is shown below.

    Configuration of GDB Hardware Debugging - Main tab

  6. Click “Debugger” tab. In field “GDB Command” enter xtensa-esp32-elf-gdb to invoke debugger.

  7. Change default configuration of “Remote host” by entering 3333 under the “Port number”.

    Configuration entered in points 6 and 7 is shown on the following picture.

    Configuration of GDB Hardware Debugging - Debugger tab

  8. The last tab to that requires changing of default configuration is “Startup”. Under “Initialization Commands” uncheck “Reset and Delay (seconds)” and “Halt””. Then, in entry field below, enter the following lines:

    Note

    If you want to update image in the flash automatically before starting new debug session add the following lines of commands at the beginning of “Initialization Commands” textbox:

    For description of program_esp command see Upload application for debugging.

  9. Under “Load Image and Symbols” uncheck “Load image” option.

  10. Further down on the same tab, establish an initial breakpoint to halt CPUs after they are reset by debugger. The plugin will set this breakpoint at the beginning of the function entered under “Set break point at:”. Checkout this option and enter app_main in provided field.

  11. Checkout “Resume” option. This will make the program to resume after monresethalt is invoked per point 8. The program will then stop at breakpoint inserted at app_main.

    Configuration described in points 8 - 11 is shown below.

    Configuration of GDB Hardware Debugging - Startup tab

    If the “Startup” sequence looks convoluted and respective “Initialization Commands” are not clear to you, check What is the meaning of debugger’s startup commands? for additional explanation.

  12. If you previously completed Configuring ESP32 Target steps described above, so the target is running and ready to talk to debugger, go right to debugging by pressing “Debug” button. Otherwise press “Apply” to save changes, go back to Configuring ESP32 Target and return here to start debugging.

Once all 1 - 12 configuration steps are satisfied, the new Eclipse perspective called “Debug” will open as shown on example picture below.

If you are not quite sure how to use GDB, check Eclipse example debugging session in section Debugging Examples.

Command Line¶

  1. Begin with completing steps described under Configuring ESP32 Target. This is prerequisite to start a debugging session.

  1. Open a new terminal session and go to directory that contains project for debugging, e.g.

  1. When launching a debugger, you will need to provide couple of configuration parameters and commands. Instead of entering them one by one in command line, create a configuration file and name it gdbinit:

    Save this file in current directory.

    For more details what’s inside gdbinit file, see What is the meaning of debugger’s startup commands?

  1. Now you are ready to launch GDB. Type the following in terminal:

  1. If previous steps have been done correctly, you will see a similar log concluded with (gdb) prompt:

Note the third line from bottom that shows debugger halting at breakpoint established in gdbinit file at function app_main(). Since the processor is halted, the LED should not be blinking. If this is what you see as well, you are ready to start debugging.

If you are not quite sure how to use GDB, check Command Line example debugging session in section Debugging Examples.

idf.py debug targets¶

It is also possible to execute the described debugging tools conveniently from idf.py. These commands are supported:

  1. idf.pyopenocd

    Runs OpenOCD in a console with configuration defined in the environment or via command line.It uses default script directory defined as OPENOCD_SCRIPTS environmental variable, which is automatically addedfrom an Export script (export.sh or export.bat). It is possible to override the script locationusing command line argument --openocd-scripts.

    As for the JTAG configuration of the current board, please use the environmental variable OPENOCD_COMMANDSor --openocd-commands command line argument. If none of the above is defined,OpenOCD is started with -fboard/esp32-wrover-kit-3.3v.cfg board definition.

  2. idf.pygdb

    Starts the gdb the same way as the Command Line, but generates the initial gdb scriptsreferring to the current project elf file.

  3. idf.pygdbtui

    The same as 2, but starts the gdb with tui argument allowing very simple source code view.

  4. idf.pygdbgui

    Starts gdbgui debugger frontend enabling out-of-the-box debugging in a browser window.

    It is possible to combine these debugging actions on a single command line allowing convenientsetup of blocking and non-blocking actions in one step. idf.py implements a simple logic to move the backgroundactions (such as openocd) to the beginning and the interactive ones (such as gdb, monitor) to the end of the action list.

    An example of a very useful combination is:

    The above command runs OpenOCD in the background, starts gdbgui to open a browser windowwith active debugger frontend and opens a serial monitor in the active console.

If you wish to use a Cyberpower UPS on a Linux system, then you'll want a monitoring daemon that alerts your PC when it's on battery power and does a proper shutdown before battery runs out. I have multiple cyberpower ups systems that I've verified this works on : CP1500AVR, CP1500AVRLCD, CP900AVR, PR1000LCDRTXL2Ua. It's likely it works on any cyberpower device. NOTE: this is for USB only, if you are using a rs232 serial connection - the below steps have not been verified.
You have a couple options to achieve interoperability, such as PowerPanel, upsmon, nut. The only one this article will explore at the moment is Cyberpower's Linux Power Panel Software. Although this article will most likely be updated with a NUT setup in the future.

Unless your distro comes with this package (Gentoo does not at the time of writing this), download the latest copy from their website : http://www.cyberpowersystems.com/products/management-software/ppl.html?selectedTabId=resources&imageI=#tab-box
Preferably the .tar package so you can build and customize as you see fit.

You can then verify connectivity with the following command :
Pwrstation company profile
You will probably want to read through this config file before customizing your own:

And the following helper scripts that come stock with this application:

Pwrstatd

The helper scripts are useful, but I started out by moving them to /usr/local/bin to maintain an orderly filesystem, then modified them as outlined below :

The following is my pwrstat daemon config with all notation removed.
Note: I don't have it setup to turn off my PC at the first power failure - as short power interruptions are common where I live - the below will only initiate a shutdown on low battery mode. Other notes are I have it setup to run until battery reaches 15% and then give 30s to launch script and another 60s to shutdown PC. Depending on the size of your UPS and power requirements, you might have to tweak those numbers to allot yourself enough time.
SIDE NOTE: I won't go into a huge recommendation and list of considerations, but generally speaking I measure my power usage for my PC and one monitor (other monitors, speakers, etc are all on the ups' surge protection only - not battery), and find a UPS wattage where I'd use roughly 60% of max UPS rated wattage. Most UPS' and power supplies have their peak efficiency around 50-60% utilization. Additionally I like to plan provide my desktop PC for around 20minutes of backup power time.

Afterwards you can restart the daemon and confirm the new settings have been applied :

Now we'll modify the helper scripts below...
First is pwrstatd-email.sh . If you wish to send an email when a power outtage has occured continue with this config, otherwise you may skip. A good thing to know is your cell phones SMS email address, which will send you a text message, very handy for instant PC alerts. If you don't know your carriers SMS address google it, for example ATT is : 10digitnumber@txt.att.net. You'll want to keep the subjects and message bodies short for txt alerts - in the below example I've added a secondary RECEIPT address and subject section for shortened text messaging purposes.
Note: this script depends on system email settings, using `mail`. I'll go through a basic setup to use gmail's smtp servers. I recommend having a gmail account used just for smtp email sending, so you don't have to keep your primary accounts password stored in a plain text file on your filesystem.

Modify the following with your login information...
Note: You do not need to include @gmail.com for AuthUser. Also for hostname you can comment out, or not include the domain if you are not a member of one.
You can test to see if the email works now :Replacing email@gmail.com with your TO: address.
Assuming that works, then next you can look over the

Pwrstation

pwrstatd-email.sh to confirm it will work with your setup:

We're going to use a centralized config file (pwrstatd-email.conf), as to not declare variables that may change inside a shell script:

Next we'll look at pwrstatd-powerfail.sh. This is the script that will run as soon as your UPS goes into on-battery mode (after whatever delay set in configuration).

Next we'll look at pwrstatd-lowbatt.sh. This is the script that will run as soon as your UPS goes into 'low battery' mode, whatever battery percentage specified above, after the configured delay.

Note: This is where you might want to add any custom shutdown options for your PC (if it's setup to shutdown here). If you have a complicated shutdown procedure, IE certain daemons stopped, work saved, etc, it might be best to create a script that does it all (if you don't have one already) then simply call that script from the end of this one. Also to note if you have multiple PC's running off a UPS - like a rackmount server setup - you can setup ssh key auth and write a script that will remote into each machine to issue a shutdown command.
After all configuration is done, save all your work on your PC and start testing.
You can start by running the scripts directly to test email functionality:

Pwrstation


If you get an error about command wall or beep not found - and you're using gentoo the following will resolve:

Pwrstat Lost Communication

With other distro's you'll have to install the relevant packages or remove those commands from the scripts.
Next disconnect the power cord from the wall to your UPS. It should turn on the battery and start beeping. Depending on how you set it up above with a delay, email, and custom notification settings - you should see that go off. You can verify the status with the following command :

Pwrstat


Pwrstation Company Profile

Finally, wait until power drains down below your set low-battery threshold - and you should see your PC do a normal/safe shutdown.