ESP-12E pinout differences

April 30, 2016 by Steve McNeil

A while ago, I found an e-book about the 8266. It’s called “Kolban’s book on ESP8266” by Neil Kolban. He compiled a lot of information on the ESP8266. I decided to look at this book to see if it has any useful information concerning the HSPI. It has very little to say about HSPI. The book lists the API calls without any detail. What is important is it lists a GitHub repository that has very easy to read example code. The author of the example code also has a blog with a very good description of how to use the SPI registers.

Since I have the HSPI working with one byte, I decided to try to get the Overlap mode working before trying to add functionality. I retested with the code from last week and got the same results. Let’s hear it for consistency! Then I put the call to hspi_overlap_init() in my code just before the sending of data. Without changing which pins the logic analyzer is attached to, I expect to see chip select to go low and but not see any clock or data, they should move to the other pins. The data didn’t change pins. I connected to the SPI bus to see if the data is being sent on both buses. I checked what should be the clk line and got what looks like data. Next I checked what should be the MOSI line and it looks like the CLK line should look. I created the table below while doing the testing. I did find that data was on both sets of pins.

Pin#(expected) — Most likely signal
PIN10(MISO) — ?
PIN11(IO2) — ?
PIN12(CLK) — ?
PIN13(IO3) — MOSI
PIN14(MOSI) — CLK

I grabbed the first build of the board to see if it acted the same. I soldered component leads to each of the SPI signals I was interested in and then attached the logic analyzer to those pins as I needed. With the old board it looks like MOSI is on Pin13 and CLK is on Pin12. There are definitely different pinouts of the ESP12E from (I assume) different manufacturers. This could be a problem if I go to any kind of mass production. There is a newer version of the chip ESP-12F that seems to match the pinout of the chip I currently have. I don’t see any evidence on the web of different pinouts of the 12F yet. This needs more research.

I will have to change the layout again but I can test the HSPI with RAM by cutting the traces and putting jumpers in to correctly wire the chip. I went back and modified the schematics to reflect these changes. Since the pinout for the 12F matches the lines I am pretty sure of, I used it to update the schematic. I changed the labels on the Pins of the chip then changed the connections to the SPI RAM.

Have you had to work with manufactures changing specs on you? Or obsoleting a chip? How did you deal with it?

New PCBs

April 16, 2016 by Steve McNeil

The PCBs arrived this week. I really like the way my Logo came out.

I do want to make an adjustment, make the arrows larger, they didn’t even show up on the silkscreen.

To start testing, I put a jumper in bypassing the lithium cell charger. I then installed the ESP-12E, the SPI RAM, The Crystal, the USB Serial Bridge, the voltage regulator, and the USB connector. Just enough to power up, load a program and test the basics.

First test was to connect to PC and run ESPlorer– it worked.

I got a message:

AT-based firmware detected. AT+GMR AT version:0.40.0.0(Aug 8 2015 14:45:58) SDK version:1.3.0 Ai-Thinker Technology Co.,Ltd. Build:1.3.0.2 Sep 11 2015 11:48:04

I then tried to install my test version of the software and it wouldn’t install. I went back to ESPlorer and started playing with the DTR and RTS to see what would happen. It turns out I got DTR and RTS backwards. So I cut the traces and added a couple of jumpers. This is the kind of mistake I was hoping to catch in the design review.

It programmed great with the wires swapped. My code crashed, back to a “Hello World” version.

Turns out the internal memory chip installed on the ESP-12E does not run at the settings I had specified with esptool.py. I found this out by setting it to 20MHz DIO mode which started working. I then switched it to QIO mode to see what happened. QIO worked, next I tried running at 40 MHz. That worked.

../esptool/esptool.py --port /dev/ttyUSB0 --baud 230400 write_flash -ff 40m -fm qio -fs 32m 0x00000 ../bin/eagle.flash.bin 0x40000 ../bin/eagle.irom0text.bin

I enabled HSPI Overlap mode by adding spiRamInit() to the end user_init(). Ran without crashing. When I started building for use, I discovered no SPI Master Read available. I saw something that looked correct for slave read, so I borrowed a line from it and did a write followed by that line– it built. I uploaded the code, and it ran, still no testing of the SPI Ram.

I added the function calls to write “Hello World” to the SPI RAM. and read back and put out to the console. and I got garbage back to the console. Not a surprise. Debugging with a logic analyzer next week.

Have you written code for the ESP8266. Have you worked with SPI before? I would love to Hear from you.

Hardware SPI test software (Firmware V00G)

April 10, 2016 by Steve McNeil

The PCBs haven’t arrived yet. So, I worked on the test code for the SPI ram.

Using the datasheet, I started setting up for SPI overlap mode. On the ESP8266 there are two hardware SPI modules. In overlap mode, they share the same pins. This means that if you use the second SPI module you can directly work with the flash memory by using CS0 for the chip select. I don’t see a lot of use for that other than for performance. If you choose a different chip select, like I am using GPIO15. You are just sharing the pins with the processor. You have to make sure your code will run in RAM while using the second SPI. ESP8266 documentation calls the second SPI HSPI.

From Microchips 23LC1024 datasheet, the sequence to write to the SPI RAM in sequential mode is:

Set CS low, write out the value 2 MSB First followed by the 24bit address to start writing at(in 3 bytes), followed by the data to be written(as many bytes as wanted up to the size of the RAM) followed by setting CS high.

A Sequential read has the following steps:

Set CS low, Write out the value 3 MSB first followed by the 24 bit address, then read in as many bytes as wanted. Then set CS high.

Side Note: MSB means Most Significant Bit. Some protocols transfer in the opposite order or LSB first. It is important to know this when setting up any serial communication. Data is clocked out on the falling edge of SCK and latched on the rising edge of SCK. The inactive state of SCK is low.

To help out Espressif provides a guide called:

ESP8266 SPI Overlap & Display Application Guid

This guide describes the SPI Overlap mode API as well as gives a reference implementation using an LCD. Unfortunately this document is missing a lot of useful information. There is a post on Espressif’s forum describing it and showing an example.

To get started I have created two new files SPIRam.c and SPIRam.h. This will make the code easier to locate and modify. To begin with I just want to write some data, and read it back and send it out on the serial connection. Basically a Hello World on the SPI RAM

I created 3 functions:

initSpiRam(); // Set up SPI and Overlap Mode
disableSpiRam(); // Shut down Overlap Mode
writeRam(char data[], int length);
readRam(char data[], int length);

I got it to build but I am unable to test it.

I still have to add a couple of commands over the serial port to tell it to write and tell it to read. I pushed a copy up to Github

I’d like to hear about the projects you are working on. Please leave a comment below.

Preparing for fabrication and population Hardware V00F

March 12, 2016 by Steve McNeil

This week is about getting the files ready for ordering. I thought about calling it Sometimes you have to do boring stuff II. I’ve pushed an update to github so that fabrication files and the new BOM are available to download.

I started by running a BOM file from PCBnew. I gave it a different name so that I could compare with the Last BOM. I opened the V00B file and then the new file called programmerV00F. I set them up so I could see the differences. There might be a good merge tool, but I don’t know of it. Line by line I started going through the components. Adding, removing, or updating each one. I deleted the lines that represented things that did not need to be ordered. This included the battery, mounting holes, and my logo. Once the obvious items had been taken care of, I went through it line by line and took counted my inventory of each item to make sure I had enough components to build one board.

I wrote the reference designator on each component bag as I went through the BOM. This will save me time as I populate the PCB. I found R5 in the BOM and I remembered I still need to experiment with it’s value, so I will pull it from a resistor kit. I skipped the charge indicator LEDs and their limiting resistors, I am not sure I want them yet. I changed my mind, I decided to get 5 each of the green and LEDs and I will use resistors out of my Resistor kit.

I ran the fabrication files to get gerber formatted layout files and the numerical drill file. I overwrote the older files because I knew that they were stored in a zip file. I then packaged them into a new zip file named UprogrammerV00F.zip. I did a quick review of the output files, and I am ready to order.

I’d love to hear what your thoughts are on this design.

Parts Placement (Hardware V00E)

March 5, 2016 by Steve McNeil

With the design review and testing done, it is time to update the layout. I started by doing a Design rules check on the schematic. I got 3 errors, two were passives connected to inputs. I changed the analog input of U10 Pin 3 to a passive pin. This is not a problem, but might be in other circuits. The third indicated two power outputs were connected together. The CH340G has a 3 volt pin that operates as either a power input (3.3v operation), or as an output (5v Operation), I went in and edited it to be a bidirectional pin. It still gave me a warning, but it’s acceptable.

Design rule warnings and errors are important, for each one, I will check to make sure it doesn’t represent a real problem and try to fix it.

I then ran CvPCB to confirm all devices have an assigned footprint. I had made some changes that means a few new components, and footprints. I got all the parts assigned and saved them. then saved the schematic sheet. I then ran a netlist. I opened the layout design, and imported the new netlist… it gave me an error. It couldn’t find the library Housings_SOT-23_SOT-143_TSOT-6. The library name had changed, I went back into CvPCB and found the TO_SOT_Packages_SMD library that had the SOT23 footprint that I needed for all of my transistors. After making reassigning the footprints, I re-saved CvPCB and the schematic file, then generated a new netlist.

This left me with a bunch of parts all jumbled together. I started by spreading them out so I could see their ratsnest better. Once I saw how much components needed to be moved around, I ripped up all traces as well as the ground plane. This gives me the freedom to re-arrange the board more efficiently. My strategy was to start at each end of the board and work to the middle.

Looking at the design, the switch for upload takes up a lot of space and is not needed. I went back into the schematic and removed the upload switch. This required that I generate a new netlist and read it into PCBnew.

I left the USB connector where it was, put the Lithium cell in the NW corner, the Reset circuit in the SW corner, the wifi module in the SE corner, The test header along the south edge, the target connector on the NE corner and the high voltage circuit along the north edge.

I routed the board using the interactive router. I then added my logo on to the board. I want to edit my logo a little bit, I may change that before I send the files off to fabrication.

The kicad files are on www.github.com, use the link just below my logo to download them.

Do you have any comments, would you do something differently, can you see a better placement of parts?

Electronics design review (Hardware V00D)

February 20, 2016 by Steve McNeil

The circuit is almost ready to go to layout again. This week I took a close look at the schematic design to look for errors and unfinished tasks. By the way, you can put notes on a schematic to help you find anything you put off for later.

I have received the PCBs for my client, but I haven’t had the chance to populate the first one yet. This means I haven’t had a chance to test the charging circuit yet. The availability of inexpensive PCB fabrication like OSH park has made a mini PCB test run reasonably priced. You can now design a development board that exactly meets your requirements very inexpensively. Since each iteration of the this design isn’t costing a lot, I am testing multiple changes each time. This allows me to work with devices that I am completely inexperienced at very low risk.

I started with the lithium cell charging circuit. I verified the input from the micro USB connector is tied to the input of the management chip. I copied the timing and current limit device values from my client’s design. The lithium cell (connector) is connected to GND and the dedicated pin on the management chip. The status outputs are tied to LEDs so I have some indication of what is happening during charging. I may try to incorporate these signals later in the design. The system power output is connected to the 3.3V regulator which is working well on the two test boards I have already built.

Next I looked at the SPI RAM Chip select logic. The transistor Q6 turns on when CS0 is low; this pulls the chip select line for U2 high preventing U2 from contending with the SPI bus when the flash chip is being accessed. There is a diode blocking the high from pulling GPIO15 high during reset. There is a pull down resistor for when GPIO15 is low and CS0 is high to activate U2 chip select. This is untested but the design looks like it will work. I chose 22K resistors for the pulldowns on GPIO15 and U2 chip select as a balance between current required when GPIO15 is high and the speed at which U2 chip select will fall when released. Since I don’t know the amount of capacitance of that circuit, I may have to change that resistor value later. Good place to put a note on the schematic.

The level shifter U3 is untested, I should test it before I go to layout. Another note.

I decided earlier that the voltage booster was working but needs to have an isolated ground on the PCB layout. I have added an inductor between the boost GND and the system GND. This allows for some experimentation. I can just bridge the pads with solder, I can put a resistor in there, or I can install the inductor. If isolating the GND is enough, that’s great. The resistor would help provide better filtering but could cause problems. The inductor is best filtering but will slow down signal transitions of the high voltage. I also gave the net name GNDpp to the isolated GND.

The transistor driver for VPP is untested, because I haven’t had the positive voltage available. I could have attached a 12 volt source and tested it but it’s a simple circuit. It should work. The analog switch is working, nothing to review with it.

Finally, the programming control pins RST and GPIO0. I am not happy with the resistor connections. I have decided to copy the design from the NodeMCU dev board. It is simple and works well on the dev board. The only thing I am concerned about here is how much current the UART bridge pulls when not connected to USB.

Use the GitHub link to get a current copy of this design. After testing, I will go to layout.

I would love to hear any questions or suggestions. If you would do this differently, please comment.

SPI RAM testing (Firmware V00F)

January 31, 2016 by Steve McNeil

The SPI RAM was still unproven. I want to test it before I do a new layout. I checked the SPI lines with a Saleae Logic16 which unfortunately can only sample 3 lines at 100MHz I was concerned that the SPI RAM would be on the SPI bus at the same time as the FLASH. This could occur anytime the CS0 and the HSPI CS were low at the same time while the processor was writing or reading from the flash. So I connected to the two chip select lines and the SPI clock line. I triggered capturing off of the first falling edge of CS0.

I configured GPIO15 to HSPICS at the beginning of user_init and it appeared to not make any difference. I then changed it to a digital pin and set it high and still didn’t appear to make a difference. So I guessed something I was initializing was causing it to change back to the mode it had been in before. I set the Pin to a Digital output and set it high at the end of user_init, and it worked. Since that worked, I tried changing the last step in user_init to set up the SPI overlap configuration. This also works. It looks like that for about 300 ms there is bus contention between the SPI RAM and the FLASH memories. This has got to be solved before I go to a new layout.

What I need is to keep the SPI RAM CS line high anytime the FLASH CS is low but follow GPIO15 the rest of the time. It’s helpful to look at in a truth table.

GPIO9  | GPIO15 | SPI RAM
 CS0   | HSPICS |    CS
--------------------------
   0   |    0   |    1
   0   |    1   |    1
   1   |    0   |    0
   1   |    1   |    1

There is only one zero in the table, this means it can be represented as an or gate. If I invert CS0 and or the signals together I would get the results I want. I figured out a circuit that would work that just adds a transistor, a diode, and a couple resistors. A PNP transistor to pull the line up when CS0 is low and a diode to block the current when GPIO15 is driven low at the same time that the RAM CS is pulled high. There will have to be a pulldown resistor to make sure the CS will go low when it needs to.

I have pushed these minor firmware changes to github.

Debugging

January 17, 2016 by Steve McNeil

I got the Sigma Delta putting out a waveform that I was looking for. But when I connected the power rail to the input of the inductor for voltage boost, the system stopped booting correctly.

I had several possible problems to look at.

GPIO16 is tied to reset on some ESP8266 modules allowing wake from deep sleep based on the RTC. I tried taking it back out of the code and I am still getting unexpected boot up activity. Doesn’t appear to be the problem, I may have to come back and have another look.

I haven’t built with the change of memory maps until last week. The bootloader may not be linking properly with my code or I may have made some mistakes pertinent to the linker. I removed the new files and recompiled without GPIO16 support and therefore a smaller memory map that fits without modification of the link files. I commented out most of the code and it still would not boot into my code. Code doesn’t appear to be the problem.

Finally, the boost circuit may draw very large amounts of current that will cause noise back into the rest of the system. Power may not be stable enough for reliable operation. I disconnected the 5V from the boost circuit and got reliable boot. I need the boost circuit to work, so I replaced the 10 ohm resistor with a 68 ohm resistor( Maximum current draw from USB would be 5v/68Ohms or 74mA). It wasn’t enough. So I tried 220 Ohms, then I tried 1KOhms. This means the maximum current I can provide to VPP is significantly reduced. I will add capacitance to the PCB on the 5V lines to allow for better noise immunity. The board is booting reliably. The problems I had earlier with the CH340G were probably related to this problem as well. I still needed to run the CH340G at 3.3V, So I am glad I changed that already.

The boost circuit is not able to create a voltage above 5v with the 1K resistor. Testing the ADC reading, I discovered I had R8 and R9 Cross labelled on the board. So I switched the labels on the layout.

The firmware is running again. I can put a pulse stream out to the Voltage Boost circuit but the 1K limiting resistor is too large to work correctly.

Functional testing for layout V00B

January 10, 2016 by Steve McNeil

For testing purposes, I chose to put the code that I can control over a serial terminal into the ESP-12E. I had to make a few modifications for the new design. The version for the last design/layout is archived on GitHub, I can easily go back to it if I find a need.

On the new design, several pins are different than before. I changed the sigma delta output from GPIO2 to GPIO4 so it can drive the voltage boost circuit. I set GPIO16 to output low to turn on the voltage boost circuit, and I set GPIO2 to output low so that the boosted voltage would be on the programming header.

I had to make adjustments to the build environment to build esp-ginx. Apparently I managed to break the build environment for the SDK in the process. For esp-ginx I had updated to the newest version of the compiler toolchain. This removed some symbolic links, so I couldn’t compile at all. I fixed the symbolic links, and I am able to compile now, however it compiles without any errors but doesn’t make a binary file. Turns out I was in the wrong folder to link properly. Next the calls to GPIO16 causing a failure to compile. I needed to bring in the files gpio16.h and gpio16.c into the project. Then the project failed to link with the errors “undefined reference to `gpio16_output_conf'” and “undefined reference to `gpio16_output_set'”. This turned out to be where I placed the file gpio16.c, once I put it in the user folder, that error went away. Then I got a new Error “`.irom0.text’ will not fit in region `irom0_0_seg'” which means I ran out of code space.

While I was looking at the makefiles I noticed a section for configuring the memory in the sdk base folder. SPI SIZE MAP = 4 or 6 both match the ESP-12E. Setting it to 4 and then 6 didn’t fix the problem. Setting BOOT = new and APP to 1 got it to compile and link without errors.

I installed the new code and I get the menu up on my terminal window.

The sigma Delta doesn’t seem to be outputting anything on any pin. This means more testing.

Javascript

December 26, 2015 by Steve McNeil

Merry Christmas!

The PCBs came in today, they look great. Of course I will need to make the modifications I mentioned last week. I haven’t received the CH340G chips yet. I will wait until I receive them before I start building.

This week, I wanted to add a slider to set the Sigma Delta output that drives the voltage booster to the web interface. I didn’t know javascript at all so, I went to an online tutorial at Codecademy.com. This tutorial is very basic and even explains the basic concepts of programming in general. I didn’t learn enough to set up a slider, I did learn enough to do some testing.

I quickly got the Sigma Delta output working in GPIO12 by copying the necessary code from the test project I was using. I then added a call to config_sigma_delta() from user_init() in user_main.c. I also added a call to set_sigma_delta_duty() from my test code in cgi_relay.c. Of course I added includes to sigma_delta.h in both of those files. I then changed the Sigma Delta output from GPIO12 to GPIO4 to match the HV_pulse line used to run the switched coil.

Now if I hit the say Hello button, It changes the Sigma Delta output duty cycle. also, the Chart on the index.html page gives the current reading from the ADC once every 5 seconds.

Prototype Iteration

The cycle of design

Tag Archives: Esp8266