Tag Archives: Debugging

Firmware Stability with Voltage boost (Firmware V00H)

by

Since there seems to be some interplay between the SPI overlap mode and the Sigma Delta, I decided to disable the SPI RAM code to see if I can get the Voltage Boost working without crashes.  I used the // comment to make nullify the lines of code pertinent to the HSPI overlap mode.  Most IDEs let you select multiple lines and type CTRL-/ to comment out a block of code, and it toggles between commented and uncommented.

Note: IDE means Integrated Development Environment. Some IDEs are very advanced and checks if your code will compile while your are typing it in.  Others are just a simple editor with an integrated programmer/compiler.  In my case, I am using a program called Eclipse as my IDE.  It is very powerful as a code editor and I could automate compiling and uploading with it, but I have taken an easier path of making a few special shell files to automate the compiling/uploading process.

After commenting out the HSPI overlap code, I verified It would compile and run.  It compiled and ran. Good so far.  Next I started re-enabling the voltage boost circuit a little at a time. First, I turned of the FET allowing the current to flow into the boost circuit.  This is done by pulling GPIO16 low.  I did this by uncommenting two lines at the beginning of serial_init. (I also made a quick edit to a comment that was erroneous) I saved that and tried again. I measured Vpp at 2.75V.

The Sigma Delta Generator was set to a prescaler of 1 and duty of 0 from the last tests I had done.  Next I started changing the prescaler to see if the behavior has changed. 98 .. 99 .. 100 rst cause:2(Failure) Next I thought “maybe it’s the WiFi Modem”, So I disabled the modem.  I added the following three lines to the end of user_init()

    wifi_set_opmode(NULL_MODE);
    wifi_fpm_set_sleep_type (MODEM_SLEEP_T);
    wifi_fpm_open(); // force modem to sleep

98 .. 99.. 100 rst cause:2 (another failure)

Next I set GPIO16 to 1 in user_init() and commented it’s configuration out in seial_init(). Same result. Next I re-enabled system_set_os_print(). Maybe it’ll give me some useful message. No new messages came across the terminal emulator. I commented out the wifi_set_event_handler_cb() line. Still fails at 100.

So user_init() now:

sets the cpu frequency,
configures all the ports, including making sure all pins are disconnected from the sigma delta,
Initializes serial communications,
Initializes the Sigma Delta,
and disables the Modem.

cpu frequency is a system call,
Ports are just register writes,
serial communications are kinda of complex,
Sigma Delta is Just register writes,
and disabling the modem uses system calls.

This points to something in the serial communications.

Looking through the uart code, I noticed the ICACHE_FLASH_ATTR for uart_recvTask();  This is an ISR (interrupt service routine), and they shouldn’t reside in Flash, they should always be in ram.  I commented out the line and tried again. Again, same failure. I decided to sleep on it.

Moving forward, I continued to look at the serial communications code.  I decided to remove all the menu display code and just display the prescaler value with each keypress.  While making this change, I noticed that I had made a string buffer called outBuf of 32 bytes long. I used outBuf to format the Sigma Delta data before sending it out the serial port.  I counted it’s length, with a Duty of 0 and a Prescaler of 100 the terminating null character would be in position 35 of the buffer(That’s a buffer overrun).  I quickly shortened the string to leave the rest of the code intact and tried again.  And that solved it.

I re-enabled the menu.
Still working.

I re-enabled the boost voltage source.
Still working

Set the duty to  51(20%).
It is still working and I measured  2.72V at Vpp (2.72V doesn’t make sense)

Turns out I had both the Vpp drive and grounding transistors turned on causing the low voltage.  I set GPIO5 low and measured again with prescaler set to 4 and duty set to 102, I measured 22V on Vpp. Success!!!(little victory dance there)

I put a //TODO comment in my code to check everywhere I am using a string buffer for possibility of buffer overruns.

Putting a comment that starts with //TODO automatically adds it to a task list in the IDE. I can then go to the tasks list to see these notes. I now have stable but highly crippled code. I have uploaded the current state of the code to Github, click the firmware link in the right column to go get it or look at it.

When you are debugging do you have a technique that works especially well for you. Do you have a technique for finding buffer overruns? I would love to hear about your experiences.

Sigma Delta still causing resets.

by

When I first built this revision of PCB, the board would reboot a lot.  That turned out to be the mis-wiring of the SPI RAM.  Part of that process in trouble shooting that board, I had guessed that I had a noisy power connection to the Wi-Fi module. So one thing that I had tried was adding a large reservoir capacitor and a small filter capacitor near the power pins of the module. Unless I am drawing too much current from the voltage regulator, this should eliminate any possible power issues.

This means my first test is to measure how much current is being drawn from the voltage regulator.  To do that I removed the jumper that bypassed the lithium cell charger and attached 3.7V to the PCB from a bench power supply.  To do this I removed all the test pins I had soldered to the module and soldered one to +BATT and another one to GND.  I connected my meter in series with the power supply and turned it all back on.  I measured the current consumed between 75 and 80 mA for the whole range of 0 to 99 prescaler.  This measurement was made with the radio inactive.

I think I can rule out the power supply as my problem.  Next I decided to change the software to take steps of 10 instead of 1 for adjusting the prescaler.  If the failure is because of an accumulated error, this should happen later and I should be able to get a number larger than 100 without a failure. I re-soldered the  bypass of the Lithium Cell charger and uploaded the change. I got to 91 No Failure. At 101 it still failed.  I change the step to 30 and when I got to 120, I got a reset cause:2. (maybe there is a clue here, This means external reset.)  I found this in the 2c-ESP8266_SDK_Programming Guide.pdf file from the Espressif BBS.

There are two pins on the module that can be used for external reset.  Since the serial to usb bridge is controlling the reset line, I decided to look into the EN pin first. It looked good with the right resistor in place to pull it up.  I then started looking through the code to make sure the Sigma Delta was configured to the correct pin.  Turns out that it wasn’t configured to output on any pin.  There was a missing statement in the code setting pin4 to output the sigma delta channel.  I added that line back in, saved, recompiled, uploaded and tested again. It still is failing.

Going back to the external reset, I decided to put lower value pullup resistors on the reset lines. I changed them from 10 K to 1 K.  This should reduce any affect of noise on the pins and still not draw too much current when pulled low. It still fails in the same way.  I have another project where the sigma delta is working very well.  The main difference I can see is that on this project I am reading the sigma delta twice before I write to it. In my other project, it reads the register once.  So I am going to make a simple uint8 variable to retain the value I am writing to the Sigma Delta prescaler.

It is still not fixed.  Have you seen this problem? Have you solved it?