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.

The Man in the Arena

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat.  –Theodore Roosevelt

This blog is one way I have stepped into the “Arena”.  Of course the dust and sweat and blood are only figurative for me. All that I risk is my pride, and reputation.  Thinking of myself a little less often is always a worthy goal.  My reputation is how I build my client base.  Risking my reputation can have a negative impact on my income.

I was reminded this week that taking risk has some advantages. I listen to multiple podcasts each week.  On the Photography Tips From The Top Floor podcast, Chris mentions that he only does most photo tours “twice only” and refers to an article that explains why.  This article reminded me that by taking chances I am stretching myself, and adding a little spice to what I do.

A software engineer has reminded me several times “If it were easy, anybody could do it.” Just because something is difficult, doesn’t mean I shouldn’t try.  I should weigh the value of trying and failing against “Aiming at nothing” and succeeding. Often, trying and failing is more valuable than not trying. Sometimes the difficult project has very little value to me even if I succeed.

Recently I have been working on a project that requires knowledge of web development.  Because I haven’t had any experience with web protocols, this has been a difficult project.  I didn’t shy away from the project because it was difficult.  However, I have found that I don’t like working in that world. For future projects when web protocols are required, I will hire out that part of the project or not take that part on in the first place.

From this experience, I am still willing to take chances, like making a voltage boost circuit without any experience.  I have also learned an area of programming that I should leave to other professionals.  This voltage boost circuit has been a great learning experience and I am still learning.  I had no idea whether I would be able to make it work or not.  I hope I have encouraged you to take a chance and try something difficult to do.

I have not received any negative comments.  Very few comments at all really.  After doing this for over a year, I had anticipated more interaction with you the readers.  How have you taken a risk recently?  Did you learn from it?  Did you succeed or fail on your goal?

Component analysis (Hardware V00G)

Last week, the voltage boost circuit would barely get above 12 volts.  This would work for most devices but I had set my goal at around 20v. I rechecked datasheets to verify I wasn’t operating out of specification.

Diode D1: The voltage across this diode is really close to 12V when Q5 is on and C14 is charged. From the datasheet, the reverse breakdown voltage(Vr) for and SD103 is 40 V.  This is a fast switching Schottky diode. This is probably not my problem.

FET Q5: The voltage across the drain to source will also reach around 13 Volts when in the off phase of the pulse stream.  The drain to source breakdown voltage is 50 V. This transistor can switch fast enough even at 80MHz.  This is probably not my problem.

Resistor R5: I chose to use 100 Ohms when I populated the PCB.  I am definitely seeing a voltage drop at C17 when driving to around 12 Volts.  If this is the problem, I will not even be able to get to 12V when running on the lithium cell. I think this is causing the problem.

To test this, I decided to change the resistor to 47 Ohms and redo my testing.

I tested with a prescaler of 0, 1, 2, and 4.  With a prescaler of 4 I got 20 volts with the duty set to 51.

Analysis and testing revealed that the filter resistor R5 was too much resistance.  By changing it’s value to 47 Ohms, I was able to get the circuit operating the way I wanted.

I made no changes to the software other than changing the prescaler.  For this firmware, that is a value that I expect to be played with, so no firmware upload this week.  I did change the value of resistor R5 to 47 Ohms.  So I uploaded a new version of the hardware to GitHub.

I would like to see smaller steps between voltages, I am thinking of changing the inductor to a smaller value to improve efficiency and control.  I am not sure this works, but it might be worth a try.

I am still working in an area of electronics I don’t understand very well.  This is the first time for me to design a switching voltage boost circuit.  Do you have any suggestions of how to do it better? How about stories about your own experience with switching power supplies.

Voltage Boost testing

I have a very stable version of the Sigma Delta(ΣΔ) firmware to test with.  I decided to use it to test the Voltage boost circuit.  I started by populating the PCB with the voltage boost components.  Definition: Populate a PCB means installing the components onto a board; this includes but isn’t limited to soldering.

PCBVboost  PCBVboostPop 

Once Installed, I started modifying the code for a simple test. The first test is a sanity check.  I disabled all functions other than sending an incrementing number out the serial port every 5 seconds. And then I ran into another problem.  I had upgraded my install of Ubuntu studio to 16.04 earlier this week and now USB wasn’t working in the virtual machine.  After a few hours of fiddling, I got it working and finally built and uploaded the test code.  The terminal started counting as expected.

Next I turned on the ΣΔ and set the duty to 16. I figured out the prescaler with the following math.  An inductor will reach approximately 2/3 saturation current after a given amount of time calculated by inductance divided by resistance.  I am using a 2 μHenry inductor with an internal resistance of 0.25 Ohms. 2×10^-6 /.25 = 8×10^-6 or 8 μsesonds.  So the most efficient use of the inductor will be between 4 and 8 microseconds. One cycle (pulse width) at 80 MHz is 12.5 nanoseconds. This results in a prescaler of 640 for an 8 microsecond pulse width. If I choose a prescaler of 255, I end up with a pulse width of 3.2 microseconds.  This is a simplified calculation and I hope it will get me close enough.  The PCB resistance, capacitors, and R5 all contribute in varying degrees. I also set GPIO16 as an output and drove it low to enable the voltage booster.  And the code ran as I was hoping for.  I measured the Vpp voltage at 5.93 Volts which is slightly above the 5 volts being supplied by the USB. Yeah! small victory.

The next firmware modification turns on the Sigma Delta and set the duty cycle to 128 (50%) .  I measured 2.75 Volts. So next I read from the ADC each time I sent to the terminal.  The value I read back was 137.  Then I enabled changing the duty with each update. and the values changed with each step.  Very good. Next I did a little math on the data. The ADC reads 1/1024 V/step.  So when I got the reading of 137, that means (137/1024)*20 = 2.675 V.

I get a small error but within 5% reading a meter verses calculated.  I fixed this by changing the 20 to 21.  I got the error because of a 5% error in the calculation of the voltage divider.  I had known about this error, but was ignoring it.  Now it is fixed.  I then started to play with the prescaler to see if i could make it work better.  The 100 Ohm resistor is having more affect on the circuit than I had anticipated.  With a prescaler of 128, Vpp rises to 8V.  At 64 Vpp rises to 11.6 V. At 32 Vpp Rises to 11.6 V again. At 16 the Vpp Rises to 11.6 again.  This suggests the design is limiting the max voltage. I need to check the reverse breakdown voltage on the diode and FET.  I would like to see better control between the steps.  With a prescaler of 0 it Vpp peaked at 12.1 V.  It took more steps to get there, and the steps weren’t linear.  It still needs tuning, maybe a different inductor.

This was fun playing with the Voltage boost circuit.  I actually got it to work fairly well.  This is the first switching boost circuit I have designed from scratch. Of course, I have had a few bumps along the way.  I have uploaded the test code to GitHub.

Have you designed a circuit that was out of you normal area of expertise? I would love to hear about your experience.