ADC and PWM V00D

I have implemented the Reading the ADC from a keystroke (R) sent over serial. I have implemented the PWM on GPIO12.  My initial testing of the PWM has a lot of jitter and didn’t perform at the frequency I configured.  I want to set up a Hardware PWM and see how it performs.  Jitter and frequency can be important when running a switching power supply, so I want to get this right. I set GPIO2 high to select Target voltage as the input to the ADC and set a variable power supply at 0.3 volts tested it and got results around 300, then set it to 0.5 volts and got ADC results around 500 indicating it’s working as expected.

The chip doesn’t have a PWM instead it has a built in sigma-delta pulse generator.  It creates a stream of pulses to achieve the specified duty cycle by adding more pulses to fill in the middle. The chip will connect the sigma delta generator to any GPIO pin I choose.  I can use any free pin to drive the boost inductor switch. If I optimize the inductor for the width of the pulse, I should get very efficient voltage conversion.

There is no API configured for the Sigma Delta unit.  I had to write directly to the registers that set the pin connection and the Sigma Delta unit.  I had to do a lot of experimentation to understand how to set up the Sigma Delta pulse generator.  There is a piece of example code on Espressif’s forum that doesn’t work correctly, but gave me the information I needed to figure out how to configure the unit.  The example code tries to be very generic, and my code is over-simplified for testing.

SigmaDelta

Functions added to test Hardware GPIO and Boost Regulator

I  have three things left to test before I re-layout the board.  The high voltage generation and the io channels, and the ADC/Analog Switch.  Since I have to control an IO pin to change the voltage output of the boost regulator, I will effectively be testing both together. I Soldered the inductor, diode, and feedback resistors on to the PCB. I will do the analog testing next week.

I start by adding a new command to the simple serial menu.  Since we are changing voltage I think tapping V is a good choice to increment the Voltage value.  First thing to do is set GPIO15 as an output and drive it low(Reset the Voltage Boost regulator). When the system displays the menu, then I set GPIO15 to a high value.  This will allows me to check the status of the pin with a volt meter. I expect it to be near zero V for about 1 second then about 3.3Vafter that until I can implement the next step.  I confirmed these values proving the gpio capabilities are working as expected. Now I should also be seeing about 6V at the test point on the output of the boost regulator. I did not see any voltage at the test point.

I need to figure out what is wrong with the voltage regulator, first, I am going back to the datasheet to verify I know how to set the voltage level. I inspected really closely and found that pin 12 of U7 did not take solder when I added the chip to the board.  With no connection on pin 12, no voltage could get to the inductor.  To fix this, I overflowed pins 10, 11, and 12, then used solder wick to remove the excess.  This still took several tries.  With the chip soldered correctly, I am now getting 7.7 volts about 1 second after I connect power to the board.

I added the V command to the parser to step this voltage. I managed to damage the boost regulator during testing. I am looking remove this regulator and implement one using the PWM. This choice will reduce the cost as well as simplify the PCB design.

Since I damaged the regulator, I decided to test the GPIO functions on an IO that wasn’t connected to anything at the moment. I chose GPIO12.  I added a command in the simple serial menu that sends a stream of 4 low pulses approximately 20 microseconds wide and separated by 20 microseconds. I chose 20 and 20 because I have a kit oscilloscope that has a 200KHz bandwidth that I wanted to test with.

I want to test PWM capability next week as well.  I have updated the code on GitHub.

GPIO12

External RAM

I found a big mistake.  The pinout I had used for the design has the SPI pinout wrong.  This means that the External RAM and the Port expander will not work until I fix this issue.  So, I found an online layout image that shows the flash chip as well as the pins.  I used esptool.py to request the flash ID.  The Flash ID manufacturer code is C8 and the device code is 4016.  Using Google, I found this to be the GD25Q32 made by GigaDevice.  This is a 4MByte spi/qspi flash chip.  I looked up the datasheet and found the following pinout.

1 CS#-------VDD   8
2  SO|     |Hold# 7
3 WP#|     |SCLK  6
4 VSS-------SI    5

CS#.....Active Low Chip Select
SO......Serial Data Output/ IO1 (Quad/Dual IO)
WP#.....Active Low Write Protect/IO2 (QuadIO)
SI......Serial Data Input/IO0 (Quad/DualIO)
SCLK....Serial Data Clock
Hold#...Active Low Hold/IO3 (QuadIO)
VDD/VSS.Power Connections

Looking at the ESP-12E Module layout, I found the following connections by tracing the tracks:

Flash CS# is connected to Pin 9 — No Change

Flash SO is connected to Pin 10 — No Change (MISO)

Flash IO2 is connected to Pin 11 — Requires a Change

Flash SI is connected to Pin 14 — Requires a Change (MOSI)

FLash SCLK is connected to Pin 12 — Requires a Change

Flash IO3 is connected to Pin 13 — Requires a Change

I also discovered that if I want to use the Built in SPI Chip selects, I need to use GPIO0(CS2) or GPIO15(HSPI_CS).  TxD is CS1 which is a conflict for testing so I can’t use CS1.  I found this in esp8266 datasheet.

To fix the pinout on the schematic, I went into the library editor and just changed the pin numbers. I left the pin order in place for the schematic.

For the Chip Selects, I connected the RAM CS# to GPIO15(HSPI_CS) and the port expander to GPIO0(CS2).

I have some other schematic changes to make, I am still considering changing to the CH340G USB serial bridge.  The problems that I have had have given me reason to consider not using it.  I may have a faulty chip, I will test with another one, and if the problem goes away, I will feel more confident changing to the less expensive chip.

I have added the SPI and SPI overlay library code to the project source. No functionality has changed, so I am not uploading the code to GitHub yet.

HSPIconnections

Simple Serial Firmware V00B

This week was focused on software.

I did a little research on my problem with the serial upload tool failing.  I found that I could update to a newer kernal that had been backported into the Ubuntu repository.  This kernel had the serial issues fixed.  So my vertual machine Lubuntu kernel is now version 3.19.0-30-generic.  Also, I wanted to try Windows 10 before installing the update on my wife’s computer.  I downloaded a copy from Microsoft and installed without a license key.  This is how you do a trial install.  You can go back and install a license key later.  With the new kernel and the new version of VirtualBox, programming the Esp-12E became very easy.

I have been using esptool.py on my circuit with no problems.  With the NodeMCU board that has the CH340G USB to serial chip still doesn’t work without modifying esptool.py. This is making me rethink changing to the CH340G chip because I just want it to work for someone that is developing new code.

I added a menu structure to the file simple_serial.c.  I copied some code out of uart.c that echos back what was sent.  I got that working pretty quickly.  Then I started reacting to the characters being received. I simplified the receive routine and passed the received character to the user interface function that I named simple_config_ui.  The user interface is implemented as a simple state machine that changes state based on the received character. I will use this menu structure to start testing the hardware such as writing and reading from the ram, toggling individual outputs, reading inputs, and setting the high voltage output level.

Remember the software as it currently stands is on GitHub.com.  Just click the firmware on GitHub link at the top or the right side bar on this page.  The software is functional and allows the user to connect to a WiFi access point by setting the SSID and Password through a serial port terminal.

TermnalConnected

Hello World Firmware V0A

I have finally created a “Hello World” project that works with the Espressif IOT API.

First, in the upper right hand side of this page is a link to the GitHub repository for this project firmware. The general rule for version systems is that you only commit if the code is runnable.  I hope to break the code up into small enough chunks that I won’t get a majorly broken version in the repository, however things happen. If I get stuck, I’ll commit broken code to the repository to keep it current with these blog postings.  GitHub maintains Versions, I’ll try to name each commit in a way that ties back to the current blog entry.  The current commit is the same as the post title, “Hello World Firmware V0A”

Things happened again,  I did a security update on my OS and the esptool.py firmware uploader stopped working altogether.  I did a quick search online and found that the pyserial library started failing with this update.  So I figured out how to roll back to the previous version of the OS kernel and I could get the firmware upload to work.

I copied the AT firmware project into the app directory and ran the gen_misc.sh script file to configure the libraries.  I had some problems with this and I feel I need to know more about how the makefile works.  The gen_misc.sh (gen_misc.bat for windows users) creates a file with the needed libraries for the project.  For GitHub I ended up moving the project to the folder named UProgrammer-Firmware in the same folder that the app folder was in.

I deleted the AT firmware files from the project directory, keeping the user_config.h file in the include folder. I then created a new user_main.c file that just set up the serial port to 115200 baud and sent the text “Hello World” out the serial port from the user_init() function.  This worked and I wanted to do something a little more in depth of the API functionality.  So I started a timer that calls my code called user_state() once every second.  I set up this function to send “Hello World” over the serial connection on the second call of it.  I also removed the sending “Hello World” from the user_init() function.  The function user_init() is called once during boot up of the processor.

I also added the commands to connect to my wifi network.  I verified this by using a utility to see what devices were connected to my network.  When I saw the name espressif for one of the devices, I knew it was connected.  I took one more step and added a new file called wifi.c and a new file wifi.h to the project.  To the file wifi.c, I copied a function from the API documentation that reports connection status changes to the serial connection.  I changed which UART is used so it would report back over the serial connection.  I put the prototype for the function in wifi.h.

Finally, I created a file called simple_serial.c and another file called simple_serial.h.  I plan on moving the initialization code into simple_serial.c to clean up the user_init() function.  I also plan on creating a simple text interface for configuring the connection details.

On the hardware side, I couldn’t re-solder the connector to the board because of too much damage so I cut a USB cable and used the A connector end with wires soldered to the board. I then used super glue to form a strain relief for the wires.

Boot Hello World

USB cable connection