Monthly Archives: January 2016

SPI RAM testing (Firmware V00F)

by

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.

SPI Enables

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.

SPI Overlap

Code Cleanup and Boost Circuit testing (Firmware V00E)

by

This week I was reading through the SDK documentation, and realized a better way of handling serial events.  I was setting a flag and using a software timer to handle those events once a second. I also found that there is a webserver example in the IOT example.  I think this server is much simpler than ESP Ginx.  I have decided to try to use this example to move forward in the design

I decided to set up an OS task that I can post to that will do things like display the serial menu.  I am already using a task for serial handling.  (I grabbed it from an example and modified it for my uses).

I started by changing the UART task to a more generic task. I changed uart_recvTask to taskHandler. Then I just call an os_event_post with the action I want taken.  This allows the system to decide when to start the action. Displaying the menu and other tasks will generally happen faster this way.

As soon as I tried to do anything with GPIO16, I got lots of reboots.  It seems that the problems I was having with the Voltage boost circuit may have actually been GPIO16 problems. I have moved the control pin from GPIO16 to GPIO13 for enabling the voltage boost circuit.  With GPIO13 connected to the base of Q4 to enable/disable the boost circuit, the firmware booted and worked reliably.  After that I changed the filter resistor back to 10 Ohms as I had originally specified. And… It didn’t boot.

I replaced the 10 Ohm resistor with a 100 Ohm Resistor.  Still wouldn’t boot. I found that if I could get Q4 turned off, then the system would boot and run reliably.  As soon as I turned Q4 back on, the system would reboot and hang. So I tried adding a 100 μF between +BATT and GND to try to filter any electrical noise. It didn’t work.

I connected a bench power supply set at 3.3V to the boost circuit input, and I got it to partially work. I got 8 volts out of it for a few seconds.  I reinserted the GPIO16 initialization functions and no problems when no power is connected to the boost circuit.

I added some code that allows me to increment or decrement the prescaler using + and – keys respectively. When I hit the – key when the prescaler was at 0 to get to 255, it would reboot. When I hit the + key to go from 99 to 100 it would reboot.  So for now the prescaler is limited to the range of 0 to 99.

I am encouraged by getting the voltage on VPP higher than any supply voltage on the board. It appears that I need to create a separate ground plane just for the boost circuit.  If I couple it to the main ground with a low value inductor, I might be able to eliminate the problems it has caused.  I have uploaded the new version of the code. It still has very little commenting, however, I think it is cleaner and easier to read.

Debugging

by

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

by

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.

 

Happy New Year

by

All the components have come in so I populated the board.  I discovered that I had ordered the wrong size for a resistor and a capacitor.  I was able to install them by bridging to them with solder. The bi-directional level shifter component is tiny and very hard to hand solder, I might be looking for an alternative to this component. I finished populating the board and added the Jumpers to fix my layout errors.

I started testing and it wouldn’t download firmware.  After hours of messing around with the design, I realized that GPIO2 was being held low through the transistor I had tied it to.  This changes the boot state. I replaced the bipolar transistor with an NChannel logic FET. GPIO15 needs to be low and GPIO0, and GPIO2 need to be High during a normal boot. GPIO15 and GPIO0 need to be low and GPIO2 needs to be high for bootloader boot.

On top of this I got my logic for Controlling RST and GPIO0 Wrong and had to modify esptool to get it to work with this design. I knew this was a possibility since I didn’t know whether DTR and RTS were supposed to be connected to RST and GPIO0 or reverse of that.  I now know that RTS is supposed to be connected to RST and DTR is supposed to connect to GPIO0 without inversion. I figured this out through experimentation.  I ended up changing the base resistors for the inverting transistors Q6,7 to 1K, removing Q6 and 7, and wiring a jumper from the resistor to the collector pad of each transistor footprint.  This allows me to program and test with unmodified versions of esptool.py and ESPlorer.

Part of the problems I had came from wiring the CH340G to 5V instead of 3.3V  I cut the supply trace and added a jumper from regulated 3.3V to pins 4 and 16 of the CH340G.

I loaded the NodeMCU firmware to verify the firmware loaded successfully. It worked well with ESPlorer. Finally, I loaded the web server firmware that I got running last week.  I have updated the schematic to reflect my changes and uploaded it to GitHub.

PopulatedPCB