Tag Archives: wifi module

Layout check … continued

by

With the new check plots I made last week, I checked the layout net by net like I did back in Sept 5, 2015. I am still uncertain about the pinout of the ESP-12F modules. To test it, I removed the ESP-12E installed on the board I am currently using, and replaced it with a new ESP-12F.  I had to be careful that the jumper wires all got back to where they were before removing the module.

The new module programmed first try but didn’t boot correctly.  I had forgot to upload default values, the flash comes programmed for a different memory layout.  Once I installed the default settings, it booted up correctly.  I had removed the test for HSPI/SPI RAM, so I went back into the code and re-enabled the Hello World ram test.

I went into serialInit() and changed the line DISPLAY_MENU(); to DISPLAY_MENU_W_SPI(); Re-compiled and tested.  Unfortunately the result was not “Hello World”. When I cleaned up the code, I made the write to SPI RAM easier, but I need to initialize the hspi.  I started connecting my mixed signal oscope to analyze what was happening on the SPI bus.  And… I found a loose jumper wire.  The one that connects the chip select between the ESP-12F and the SPI RAM. Once this was connected, the extra stuff I had put into the software became unnecessary.  I deleted the extra code and it works just fine.  The firmware is back to where it was before I started testing. There are no changes to upload.

This means that the circuit is tested and the current layout is ready to send to fabrication.  I zipped up the gerber files. Then checked pricing with PCBway, DFRobot, and Seeed Studio.  With shipping PCBway came in a little less at US $19.  With PCBway, I have to wait for a design review before they will give me a final price and allow me to pay for it. Usually this is pretty quick but depends on the day it is submitted.

Have you bought boards from Chinese manufacturers? How quickly did you get them?

Update to SDK 1.5.4 Firmware V00J

by

Since I don’t seem to be making any progress on the Sigma Delta output, I decided to update my copy of Espressif’s API. I went to bbs.espressif.com and clicked on the SDKs thread under the heading DOWNLOADS. In the list i looked for the most recent Non OS SDK release.  I saw that ESP8266_NONOS_SDK_V1.5.4_16_05_20 is the most recent release. It’s file name indicates a release date of May 20th 2016.  I downloaded the zip file and extracted the contents.

To Make moving forward a little easier, I renamed the SDK folder to UProgrammer.  This will help me maintain paths the next time I move to a new SDK Version.  Each time I update to a new SDK, I will Rename the OLD SDK folder to indicate it’s version number, and rename the new SDK folder to UProgrammer.  To maintain compatibility with Github’s folder naming, I will continue to keep the UProgrammer-Firmware folder name for the project files.  This folder will be sitting in the SDK folder I just renamed to UProgrammer.  I then created an empty text file with the name of the SDK file to mark the version I am working in.  Then I copied the hidden file .metadata from the old SDK folder into the new (UProgrammer) SDK folder.

I opened eclipse and pointed the workspace to the UProgrammer folder and it loaded the files as if I hadn’t changed anything. Then I made edited the comment block at the top of the file to indicate I had moved to NONOS SDK V1.5.4.  I saved the file and then checked the file in the new directory structure for the changes. It has the change I had just made.  To make sure there wasn’t something weird going on, I also checked the file in the old directory structure. It was unchanged.  I had planned on dealing with more problems just in case they happened.

I compiled the code to see if anything broke moving to the new SDK.  Things definitely broke. First the files all compiled but linking failed.  The first error message was:

section `.irom0.text' will not fit in region `irom0_0_seg'

This reminded me that I modified the linker file eagle.app.v6.ld to allow for more room for the code space in a 4MByte flash chip.  I made the modification to the new file and saved it.

Modified linker file

I tried compiling again.  Again it failed to link but I was no longer getting the memory failure. This time the first error message was:

 undefined reference to `uart0_sendStr'

I didn’t have the most recent programming reference, so I went back to bbs.espressif.com to download it.  I got the 2C-ESP8266_SDK_API Guide_EN_1.5.4.pdf.  It turns out uart0_sendStr() isn’t in the documentation.  So I looked in my code to find it.  I found the prototype for it in uart.h. but it doesn’t appear anywhere else. This makes me wonder how I was compiling last week.  I did find it in uart.c in the drivers folder.  At one time that file was part of the project. I am guessing the object file was still getting linked in to the project.  The compiled object files are in hidden folders and didn’t get copied by default.  (It’s a good thing.  The versions of code on Github would not have worked. Now they will get fixed.)  I copied The code for uart0_sendStr() into simple_serial.c and recompiled expecting it to fail because uart0_sentStr() calls something else in uart.c.

Again I looked at the first error from the linker which was:

../lib/libat.a(at_ipCmd.o): In function `at_set_rx_buf_state':
(.irom0.text+0x10ac): undefined reference to `espconn_secure_sent'

I am not using any secure features or any AT functions, so I decided to look at the make files. I used a Linux tool called meld to compare files.  There were very small differences.  Looking at my makefile, I noticed four lines that effectively added the -lat linker option.  I commented out those 4 lines and recompiled.  Now the linker only has 4 errors remaining, all of which can be fixed by copying code from the uart.c file.  After copying each function I needed from uart.c, I finally got a successful compile of the code.  I then uploaded it to the PCB to see if it still runs.  It ran the wrong code.  I now get a message in the serial terminal “dmode : softAP (XXX) indicating it is booting up as an access point.

I was able to connect to the device and dhcp worked, but an attemp to connect by http was refused.  Since the messages are system messages I decided to try a UART Swap. No change in the behavior.  I need to do a sanity check, this is a new API so back to doing a Hello World test. I finally got confirmation that my code is what is being uploaded to the module.  I placed the following function call:

system_set_os_print(0); // Turn off System Messages

into the code. I am no longer getting any output in the terminal.  I wasn’t getting any error from compiling but it turns out the function uart_tx_one_char() needed to be copied from the uart.c to simple_serial.c I chose not to have uart.c to reduce code size, there is a lot of code in uart.c that I will never use.

I cleaned up some of the things I tested recompiled and posted a new copy to Github. Do you have any tips for migrating between environments? I’d love to hear about them.

Understanding HSPI Firmware V00H

by

What I wasn’t understanding last week is the definition of HSPI_CS.  It is the same as CS0 in the HSPI module.  So when I turn on overlap mode, of course, it maps to SPI_CS0.  That leaves me with setting the HSPI to use CS1(GPIO1/U0TXD) or CS2(GPIO0).  Since I use U0TXD for reprogramming the module, CS1 is unavailable.

I cut the trace going to U2 CS0 and added a jumper wire to GPIO0.  I then changed the code to use CS2 to enable the RAM.  This included setting the HSPI to use CS2 and setting GPIO0 MUX to be SPICS2.  And I got what looks like a successful write to the SPI RAM.

Successful SPI Write

The byte command (2) followed by 24bit address (0) followed by the data.  The first four bytes of data are “lleH”.  This is backwards to what I was planning, I can change it by setting a bit or changing the bytes I put into the registers. As long as I read them back the same way, it really doesn’t matter as long as I read and write aligned to 4 byte words.  The data is one byte short, I had a typo sending only 11 bytes of data.

Note: When data is aligned to 4 bytes, it means you need to read or write only on increments of 4 bytes.  So you would only Write or Read to/from addresses that in hexadecimal end in 0, 4, 8, or C. Since this chip is a 32 bit processor, this is required often.

I then decided to implement the hard coded read command.  I copied the write code, changed the command from 2 to to 3, set the HSPI to read back  and zeroed out the working registers so that I can see if they have been filled with the data I stored in the RAM. Then I commented out the writeRam() call in user_init and added readRam() in it’s place. Doing this without powering down, I should get the data back without having to write it again. I forgot to switch the length to the receive length register; I fixed this then I got back all zeros for the data.

Unsuccessful SPI read

I see the command (3) followed by the address (0) followed by 12 Bytes of data(0). So I have more debugging to do.  My first guess is the WP or HOLD lines of the chip are not doing what I need them to do.

I have gotten a better understanding of the SPI hardware on the ESP8266.  It looks to me that I can get the same control by just using the main SPI channel to control my RAM chip.  This needs testing.  I will need to save any registers I change and restore them when I am done accessing the RAM.  This will also have to be done from code that runs from internal RAM.

I have put the current state of the code on GitHub.  Use the link under the search box on the right side of this page.

Have you used chips with similar SPI configuration?  I like that I can have any bit length of data on the SPI bus, this will be useful for JTAG data. Have you worked directly with JTAG data?

External RAM

by

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

by

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

by

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

Radio Option 4

by

The EMW3162 is a Wifi module with an integrated ARM Cortex M3 processor running at 120 MHz.  Having the processor integrated into the module eliminates some of the more difficult layout requirements. Most of the potential RF problems are already taken care of by the module designers.

The clock for the SPI will be running around 30 MHz in extreme cases.  At this frequency I might have to treat the signal paths as RF and will probably need filters and shielding.

Note: RF means Radio Frequency. It is used here to denote any signals that could escape the system as radio waves and cause interference.

Device Advantages

  • Integrated ARM processor with 30 Mbps SPI interface
  • 5 V tolerant pins
  • USB capabilities (possibly used to update firmware/or configure wifi)
  • simplifies hardware design
  • About US $10 each
  • 1 MB Code space(should be more than enough providing WiFi Stack is not huge)
  • Several different library options.

Device Disadvantages

  • Share processor with WiFi stack
  • Will need better understanding than stand alone wifi/bluetooth stack (This means longer learning curve)
  • I am unfamiliar with STM32 processors