Hardware Iteration (hardware V00H)

The last time I worked on the electronics was when I got the switching boost circuit working.  The crashes I saw with it is why I did so much code work since then.  This week, I wanted to get back into electronics.  Since it has been a while I started by reviewing the schematic.  First thing I reviewed was the Lithium cell charger circuit.  It matches the reference design in the AAT3672 datasheet and it matches the PCB.  I should test it before I spin another set of boards.  I put a note on the schematic to remind myself to do that.

I then looked at the switched boost circuit. It turns out I don’t need L2, the real problem was in software. I removed L2 from the schematic. The resistor R5 was changed to 47 Ohms. I updated that on the schematic.  Next I looked at the USB to Serial Bridge, I have two cuts with Jumpers on the board, I checked them against the schematic. The schematic matches the patch I had made.

Next I compared the patches I made to the SPI RAM against a pinout of the ESP-12F I found online.  ESP-12F pins 9 – 14 on the schematic matches the PCB with the modifications I have made.  Pin 16 is no longer connected and Pin 18(GPIO0) is connected.  I had made this change back when I was testing the SPI RAM. With this change, D4, Q6, R26, and R27 are unnecessary. I removed them from the schematic and tied GPIO0 to U2 Pin1 and disconnected it from U10 Pin 6. I then tied GPIO15 to U10 Pin6 with a net label called A_SEL.  I have yet to test IO2 and IO3, Which will require running the RAM in QIO mode. In QIO mode, IO2/IO3 shouldn’t matter because when I read them back out of the RAM will come back out on the same pins they went in.

I have yet to test the level shift chip(U3).  I don’t like how hard U3 is to solder so I researched a different part to do the same thing. The new part I found is a TI TXB0108PWR which works very nearly the same as what I already had designed in but comes in a 20 pin TSSOP which is easier to solder.  The Pin order is different. The part is only US $1.88 in singles at Digikey.  I proceeded to change U3 to the new part on the schematic.  The datasheet recommends that OE be held low until both Vcca and Vccb are on.  I put a PNP transistor in to pull OE low anytime Vt is not driven.  As I dug into the datasheet, I found that this chip would not work for I2C.

So I did a little more research and I found another chip from TI.  The TXS0108EPWR works with SPI and I2C.  It has the same pinout as the TI TXB0108PWR so adding it to the schematic was really easy, I changed the name in the schematic.  This part is US $2.00 on Digikey.

txs0108esch

I uploaded the updated hardware design to Github. Click on the hardware link in the right column to go get it.

Have you used level shifters before? Have you decided on a chip only to find out that it was missing one crucial component? How did you fix it?

Hantek MSO5202 Mixed Signal Oscilloscope review

mso5202d(Picture taken from Aliexpress.com)

Features:
This scope has 2 analog channels and 16 digital channels With Bandwidth up to 200 MHz.
1 Million sample points for the analog channels.
512K sample points for the Logic Analyzer channels
7 inch 800×400 color LCD display
USB Host for flash drives
USB client for PC control

Pros:
Capture 16 channels digital and 2 channels Analog simultaneously.
Export captured data to CSV file (useful for analysis)
Linux based (hackable!)
Familiar knob/face layout
Bright clear display

Cons:
No protocol analysis built in. No way to add protocol analysis.
No Linux PC support
Occasionally crashes
D0 is only digital trigger line

My experience with this scope:

The Purchase:
I bought the scope off of Aliexpress.com.  I knew I wanted at least 100MHz Bandwidth. I also didn’t have a lot to spend.   There wasn’t a big cost savings to go to the 100 MHz scope, so I decided to go ahead and get the 200 MHz Version.  Since I have bought the scope, I have seen information on how to hack the 60 or 70 MHz models to get the full 200 MHz performance. Assuming the scope lives up to their specs, I am happy to pay for the Higher bandwidth.  This scope is still a bargain with a price less than $500 US.  The seller shipped it to me for free with DHL shipping. The scope was delivered within 7 days.

Unboxing:
The scope came in the manufacturers box inside of another box it just fit inside.  I cut the tape on the outer box and opened it to see a handle on top of the manufacturers box.  I started to lift by that handle and the bottom of the manufacturers box fell out.  I had only lifted it a few inches so the bubble plastic protecting the scope protected it from damage.

First use:
I connected the power cord and nothing else. Turned on the power and it booted up quickly (less than 10 seconds). I then dug out the probes and hooked them up. The probes came with color rings to help identify which channel I was using.  Both probes came with red rings on both ends of the probe.  I looked at the scope and saw that the color for channel 1 is yellow and the color for channel 2 is blue.  I grabbed one of the probes and switched the colored rings to yellow and connected it to channel 1.  I repeated that process with blue rings for channel 2.  I connected the probes to the calibration tang on the front of the scope and did a quick adjustment of each probe.  The knobs have a good feel to them and the waveforms change the way I anticipated for each turn.  This made this scope feel very familiar.  All of this was done without reading the manual. So far so good!

Tinkering:
I have a circuit that the LCD got damaged on and I wanted to see how the Logic Analyzer worked.  The LCD is controlled by SPI. I hooked up the data lines, figured out how to trigger off of D0 and it kind of worked.  It wasn’t real clear how to get to the Logic Analyzer to begin with. I found it with playing.  Then I figured the chip select line of the LCD would be a good choice to trigger off of.  There is a short glitch just after power up that meant the scope triggered way too early.  I was disappointed that I couldn’t change the trigger to a different digital channel, I had to move the connections around instead. To make the connections to the LCD, I had to solder several 30 gauge wires to the data lines I was interested in. These wires are fragile so changing the connections to them was difficult.  The scoped locked up or did weird things while I was tinkering.

Data Capture:
I was also disappointed that there was no simple data analysis for the Logic Analyzer system.  I captured a chunk of the LCD SPI data and saved it as CSV file to a flash drive.  I put the flash drive into my computer and opened the CSV file with LibreOffice Calc.  With some complex cell calculations I was able to get Calc to show me the data that was sent for each time chip select was active. The good news is it showed me the circuit wasn’t damaged and a replacement LCD should fix the device.(The scope served it’s purpose)

Overall:
I found this scope to be very intuitive to use for analog signals.  The Logic Analyzer function is very useful but is not very intuitive and is missing some features.  If I had this when I was testing the SPI on the Uprogrammer board, I would have found my problems much quicker.  I watched a few of the hack videos on YouTube. They connect a USB to Serial bridge to the system and issue a few Linux commands. Linux is a great place to start hacking. On the back is a punch out with a Networking symbol next to it.  If it turns out that there is a chip that supports ethernet on the board, I would like to install the ethernet jack and see what happens.  From the hack videos, I can see there is a place on the PCB for the ethernet Jack.

My Opinion:
This an excellent scope for the price.  I have seen online videos that indicate problems when approaching the higher bandwidth limits of the scope.  I don’t believe these problems will affect me.  If you need high precision in near 200 MHz, I would suggest looking for a better scope.  Otherwise this will make a fine tool on your bench.  Firmware is still being developed for this scope, so I expect it to get better over time with updates. Since it is Linux based I also expect the community to hack it for better features than just a bandwidth upgrade.

Have you used one of these scopes?  Have you worked with one near 200 MHz?  What is your feelings about the lack of digital features? How about the occasional lock up?

Finishing cleanup Firmware V00

I decided that the code that interacts directly with the hardware registers can’t be rewritten to be much clearer to read. There should be a lot of commenting in the code explaining why the registers need to be set that way.  That is a big project and since I didn’t write most of that code, I don’t understand a lot of it.  I am choosing this week to just make sure this code is formatted in the Allman style and leave commenting for later.

I have now worked through all the .c and .h files in the project to made sure they are formatted in the Allman style. I decided to go back through all the names used for variables, functions, constants, and macros and format them all the same.  Since Espressif named all the system calls in lowercase underscore separated, system calls will follow that format.

The rest of the naming I decided as follows:

Macro: All caps with underscore separation followed by ()
DISPLAY_MENU()

Constant: All caps with underscore separation
USER_TASK_PRIO_0

Variable: Lower camel case
menuState

Non System functions: lower camel case with ()
getNewPassword()

I used Eclipse’ refactor feature to make these changes to all the files at once.

I had a couple of .h files that didn’t refactor correctly, but once i got those fixed, the code compiled and ran just like before.

The firmware is getting easier to maintain and edit.  I hope to move forward with the electronics design again soon.  I bought and received a new mixed signal oscilloscope and received it this last week, I plan on doing a review of it next week. I have uploaded these changes to Github, click the link in the right hand column to get the firmware source.

Have you used Eclipse’ refactor function before?  Did you have similar problems?

Simple Serial Cleanup V00J

Because of the size and complexity of simple_serial.c, I decided I would work on cleaning it up for this week’s post.

To start with, I created two new files for postable events called events.c and events.h.  I moved the function task_handler() from simple_serial.c to events.c and added a //TODO comment to remind me to clean up the task handler code.  This created a bunch of errors because I haven’t included any of the library header files.  So I stepped through the process of adding the necessary header files.  I copied all of the include statements from simple serial.c to events.c and eclipse reported no errors.  Next, I commented out one line at a time of the include statements. When eclipse indicated errors in the file, I uncommented that line and moved on to the next.  I ended up only needing two include statements: uart.h and user_interface.h.   I moved the prototype of task_handler from simple_serial.h to events.h. Then I put an include statement into simple_serial.c for events.h.

I decided this was a good point to build to see if I had broken anything. It failed to build.  The error I got was

In file included from simple_serial.c:22:0:
../include/events.h:14:1: error: 'task_handler' used but never defined [-Werror]
 task_handler(os_event_t *);
 ^

The LOCAL keyword was making task handler only available to events.c.  I removed the LOCAL keyword from both events.h and events.c and got a new error.

user/.output/eagle/debug/lib/libuser.a(events.o):(.irom0.text+0x2c): undefined reference to `os_sprintf'

It looks like eclipse did not report an error when I removed one of the include lines.  I went back and added one of them at at time till the error went away.  The missing include was osapi.h  The code built and I tested it on the board. It booted and connected to the wifi as expected.

Next I created some macros that I will use when posting a task for serial events.  Now serial_init() is much easier to understand.

Next, I took on simple_config_ui().  First I started by looking at the biggest case statement which had another switch/case statement enclosed. When menu_stat is equal to IDLE, there is a switch/case for handling received characters;  I created a function called recv_byte(char recvd), copied the code and made a few little changes to make it compile and run.  I continued this process of taking large chunks of code and putting them into functions.

Finally I created a new uart.c and moved the code I originally got from uart.c out of simple_serial.c into uart.c. It took a little fiddling to get it all working again.  I have uploaded this update to Github.  Click the firmware link near the top of the right hand column to download it.

Are you cleaning up code? Did you learn to write “easy to read” code in school? How did you learn to write code? Are you learning to write code now?

More code cleanup

I spent the time on this project this week cleaning up the code to match code style and better documentation.  Boring things just have to be done.  I would say in most projects, that approximately 50% of my time is spent on stuff that needs to get done but I don’t enjoy doing.  If you get a good team, this percentage can be reduced.  For instance, some software developers enjoy and even find fascinating the stuff I find boring and tedious.  So if you have a team that is well filled out, then each person gets to work on the stuff he finds interesting.

There will always be some areas that need to be done that no one on your team finds interesting to do and it will just have to get done.  It can be assigned, or just fall to the most relevant team member.  Sometimes the task is shared.

Of course for the Uprogrammer project, I am the “team”.  This means all the tasks (boring or otherwise) fall to me.

This week I worked on the following files.

gpio16.c — reformatted style, no other changes

sigma_delta.c — reformatted style, removed excess comments and dead code

simple_serial.c — reformatted style, skipped editing(big project)

spi_overlap.c — reformatted style, removed excess comments and dead code

SPI.c — reformatted style, removed excess comments and dead code

SPIram.c — reformatted style, removed excess comments and dead code

After all these changes, the code still compiled with no errors or warnings. This is all I had time for this week. I have uploaded these changes to GitHub. Use the link at the top of the right column to download it.  No version change, no functional changes.

I would love to have help on this project. Do you find this project interesting? I could use help in all aspects of this project especially firmware development.  Would you like to be a developer on this project? What parts of this project do you find interesting?

Code Style

Along with self and or well documented code, there is a way to format the code.

A style guide (or manual of style) is a set of standards for the writing and design of documents, either for general use or for a specific publication, organization, or field. (It is often called a style sheet, though that term has other meanings.) from Wikipedia.

In software(and firmware) coding it is good to follow a style guide.  Some software developers are very passionate about which style they follow.  My opinion is to pick one that you like you and stick with it. When working on code that was not written by yourself, you should match the style of the original author.  I am not passionate about which particular style to use, but I believe that a project should follow the same style in every file.  When the compiler or interpreter doesn’t require specific details, things like indent size, block placement, and capitalization, are left to the programmers choice.

I have not chosen a particular style. This week I am looking at the common coding styles that are used.  I intend to pick one for this project.  I want to choose wisely because I will probably use whatever I choose on all subsequent “C” projects.  I want to choose a style that is popular because, I want a high probability of seeing it in other code I will be working with.  I also want a style that is easy to read. I don’t care whether tabs or spaces are used for indenting, or how far indenting goes.  I found a good article describing why to use and adhere to a style guide.

One thing I found useful in that article, is that Eclipse has a code formatter that will verify your code follows a particular style.  There are four built in “C” code styles: K&R, BSD/Allman, GNU, and Whitesmiths. If I type Shift+Ctrl+F while a source file is selected, Eclipse will apply the style to the whole file.  A online poll I found indicates Allman and K&R are the most commonly used.  I personally like the Allman style better.

I have decided on the BSD/Allman style moving forward with this project.

Do you have a particular coding style you use.  What are it’s advantages and or disadvantages?

Good Enough

Designing anything new rarely goes as expected.  Of course you try to design as much as possible using technology and designs you are already familiar with.
I was working with a monopole wire antenna this week.  I needed to tune and impedance match the antenna to be as efficient as possible between 905 and 930 MHz.

The tool I had available to do this tuning with is a Spectrum analyzer with a built in Tracking Generator and an external return loss bridge.

Note: For optimal transfer of energy from a transmitter to an antenna, they have to have the same impedance.  Most rf transmitters are designed with an output impedance of 50 Ohms. This means that the most efficient antenna will have a characteristic impedance of 50 Ohms. The characteristic impedance of an antenna depends on it’s length and it’s surroundings.

When the impedance doesn’t match, a matching network is needed to fill in the gap.  If an antenna looks more like a capacitor than an inductor, then a series inductor can be used to make up the difference.  If the antenna looks more like an inductor, then a series capacitor can bring it back to close to 50 Ohms.  Of course the series inductor or capacitor will burn a little energy but most will get transfered to the antenna.

The antenna I worked on this week tuned fairly easily around 860 MHz.  When I cut the antenna shorter for 915 MHz, it became very hard to tune.  My job would have been a lot easier if I had a network analyzer that operated in the 900 MHz Range.  An analyzer would have told me the characteristic impedance of the antenna as well as whether it was more inductive or capacitive.

I didn’t have the a network analyzer and was under a time and budget constraint. My solution was to put different inductors in series and see if that would work. It worked great at 860 MHz. It didn’t work at 915 MHz.  My next idea was to put a capacitor in series, the only capacitor I had that would fit on the PCB was a 0.1uF.  This would be too high of a value of reactance to be useful.

My next idea was to put an inductor to ground to reduce the inductive reactance of the antenna.  This produced mediocre results.  I could only get about 85% efficiency from the antenna in the 900 MHz Band.  I tried successively larger values looking for the best return loss.(most emitted energy).

I had to settle for “Good Enough”. If I get the chance, I would like to go back and buy a capacitor kit that will let me try the series capacitors.  The antenna will work well, but the overall range of the radio will a little bit smaller.

Have you had to settle for good enough?  What are your thoughts about how “Perfect is the enemy of good”?

Code Documentation Firmware V00J

I Know that my code is very poorly documented.  So I want to focus on organizing and documenting the code.  To start with, I started looking for online classes that teach documenting code.

I found very little about commenting code.  I did find an interesting article I need to think about a bit more. The general theme of this article is to write code in such a way that comments should be rare.  For instance, code should probably be re-written if it needs comments to explain it. Variables should be named in a way that describes what they contain.

I was just about to give up searching. I was thinking I would start by putting header comments before each function or method.  This article gives pretty good reasoning not to do that. So this week, I decided to look at just one file — user_main.c.  Git does line by line version control.  I decided on one small header block at the beginning of the file.  This header block will indicate the license, original author, and/or the template source.

I looked to the header comments to know what to pass to and get back from a given function.  I have decided to make a new document that describes in better detail how to use each function.  This new file will be called UprogrammerFunctions.txt.  Since I removed the Comment block from in front of user_rf_cal_sector_set, That is the first function I am documenting in the API.

There is a big block of code in user_init() that all it does is set up the IOs to their initial states.  I copied that code into a new function called setup_io_pins() at the end of the user_main.c file. Next, I deleted all the test code I had commented out.  Finally, I made a couple of macros in user_config.h called VOLTAGE_BOOST_ENABLE()  and another one called VOLTAGE_BOOST_DISABLE()

Note: My definition of a macro is the use of a symbolic reference to represent other code.  In this place, I am using VOLTAGE_BOOST_ENABLE()  to represent  gpio16_output_set(0) to make it a little more clear what is going on. I also created a function in wifi.c to set up the wifi modem called wifi_init() and also put a prototype of wifi.init() in wifi.h.  I then moved the two wifi calls out of user_init() into the function wifi_init().

I tried to build and the call to the new function setup_io_pins() caused a linker error.  I needed to create a prototype of this function. I put it in user_config.h and it compiled, I uploaded it and it ran just like before I started cleaning up the code. I believe my user_main.c file is much more readable now.  I have uploaded the new version to GitHub. Click the firmware link in the right column of this page to go look at it or download it.

I would like to hear about your experiences cleaning up and commenting code.  What are your preferences for commenting code.

New Release of Espressif’s SDK (Firmware Version 00I)

Espressif released a new version of their NonOs SDK.  The new Version is 2.0.0 released on July 19, 2016.  The change from 1. something to 2. suggests it might break the code.  I downloaded the new version.

Last week I crippled the software for debugging purposes. I found the bug. This week I want to update to the new version of the SDK.  Since it might break my code, I want to get all the functionality back in the code before I move to the new SDK.

First, I uncommented the HSPI overlap test code. I made a small change to the code that reads out from the SPI RAM to guarantee there is a null terminator in the 13th position of the buffer that is filled from the SPI  RAM. Then I compiled and tested it. It immediately crashed.  I am really glad I haven’t upgraded the SDK yet.

I put hspi_overlap_deinit(); directly after the call to the writeRam(); function. It didn’t crash, but I didn’t get the Hello World from the SPI RAM.  I need to init and deinit hspi overlap mode in the writeRam() and readRam() functions. I modified these two functions and tried again.  Now I get the Hello World after the menu after a reset.

Next, I enabled the WiFi modem.  I set the wifi opmode to  STATION_MODE and commented out the other lines that disabled the modem. It booted, I set the SSID and Password, requested a connect and no apparent result.  I remembered the WiFi Callback is still disabled, I uncommented that and tried again. This time, it remembered the settings from the previous try and connected immediately.

Next, I re-enabled the Sigma Delta circuit and tried changing values.  It is working without crashing.  The code is where it should have been before the buffer overrun bug.  I am ready to upgrade the build environment.

I am going to use this code as my base going forward because the web server code was unstable, and I don’t want to work with the web protocols as much as that would require.

I did some of these tests while the file was downloading from Espressif’s website.  I ran make with the clean option. This removes all the intermediary files used in compiling. Next, I copied the folder I was working with to UProgrammer-SDK1.5.4  This gives me something to go back to if the upgrade fails.  Next I opened up the zip archive of the new SDK.  I copied all the files and folders in the ESP8266_NONOS_SDK into the UProgrammer folder.  This copies over all the SDK files but leaves all my files in place.  It does mean the linker file I modified will get overwritten as well.  I checked this file and they have changed it in the new version of the SDK.  It doesn’t match my linker file, but it might have enough room for my code.  I decided to try compiling without modifying the linker file.

There are linker errors but they are not based on code size.  They describe undefined references to user_rf_cal_sector_set in function flash_data_check.  This looks like a makefile error.  I compared the makefile in the app directory with the one in my project directory.  There was no makefile in the app directory like there has been in previous versions of the SDK.  I went into the examples folder and used the makefile from the IOT_Demo Example for my comparison.  I did some clean up and made some changes to make the files closer to each other.

The changes I made weren’t enough, So I copied the whole file over to see if it fixed it. It didn’t, It looks like a file library file isn’t being linked in. I went into the lib directory looking for the library I needed to link. user_rf_cal_sector_set sounds like a memory function to me. So I looked for a library that dealt with calibration memory.  In the include directory, used the following command line:

grep -r user_rf_cal_sector *

and I got no results back, so for a sanity check, I tried the following command:

grep -r smartconfig *

and I got a list of lines with smartconfig  listed.

On a hunch, I decided to remove the link to main. In the makefile under LINKFLAGS, I removed the line -lmain \.

That also didn’t work.  I did the following command in the UProgrammer foler:

grep -r user_rf_cal_sector *

The result looks like every example implements this function. So I copied that function into user_main.c from the IOT_Demo user_main.c and it turns out they required this new function because they changed the layout of the flash calibration data. Now it builds.  Now the code no longer works.

I tried changing the ld file back to having a length of 0xC0000 and I noticed that the build said I should upload the code to 0x10000.  My shell scripts upload the code to 0x40000.  So, I restored my makefile from the copy of the folder and tried again. It still builds to load at address 0x10000. I modified my script file to load to that location.

And finally, success.  I set the SSID and the password and requested a connect. it seemed to stall.  I reset the board and it connected immediately. I am going to have to take a look at that.

I tested the Sigma Delta and that worked as expected. I measured 22 volts on the output with a duty of 102 and Prescaler of 4.

I re-uploaded the default settings and tried again. I set the SSID, Password, and requested a connect. it seemed to stall again.  I waited ten minutes to see if something would change.  I looked at the connect request code while I was waiting.  Somewhere along the development I deleted the actual call to connect.  I didn’t make it to the full ten minutes. Put the connect request in the code, compiled it, reset the flash to defaults, and uploaded the new version.

This time it connected in about 5 seconds. Success. I have uploaded the new version of the code to GitHub, click the Firmware on GitHub link at the top of the right column to go get it or just take a look.

Please comment below about your experiences upgrading to a new version of API/APK.  Maybe you have had similar experiences switching between devices in a processor family?  I would love to hear from you.

Firmware Stability with Voltage boost (Firmware V00H)

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.