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.

Sigma Delta still causes reboots Firmware Version 00E

I was hoping but not expecting the SDK Update to fix the Sigma Delta problem.  So first thing I did this week was to test.  Same failure as before.  I had two Ideas this week that might be an answer to the problem.  On another project, I was using the Arduino IDE to develop a little weather station project.  In it, I was using old code that set certain pins as output.  Those pins were/are tied to the SPI bus and was causing it to reboot.  Maybe, there is a pin set to have Sigma Delta(ΣΔ) output that is also tied to a critical pin.  My second thought is that if the ΣΔ is causing interrupts, I should disable them.

A good practice for microcontroller programming is to always set up all I/Os immediately after a reset.  I have gotten sloppy and haven’t done that with this project. If a pin is connected to the ΣΔ that shouldn’t be, this will fix that.
I started by writing down what each pin will do in the design. I referred to the schematic for each pin.

Pin 18 GPIO0 -- Output -- controls analog switch
Pin 22 GPIO1 -- Output -- TxD0
Pin 17 GPIO2 -- Output -- sets VPP output high
Pin 21 GPIO3 -- Input -- RxD0
Pin 19 GPIO4 -- Output -- ΣΔ pulse stream to generate Vpp
Pin 20 GPIO5 -- Output -- Sets Vpp output low
Pin 14 GPIO6 -- Output -- SCLK (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 10 GPIO7 -- BiDir -- MISO (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 13 GPIO8 -- BiDir -- MOSI (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 11 GPIO9 -- BiDir -- QIO2 (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 12 GPIO10 -- BiDir -- QIO3 (SPI and HSPI overlap) (need to verify Pin number for ESP12F)
Pin 9 GPIO11 -- Output -- CS0 (SPI) (need to verify Pin number for ESP12F)
GPIO12 -- BiDir  -- Data to target device
GPIO13 -- BiDir  -- Data to target device
GPIO14 -- BiDir  -- Data to target device
GPIO15 -- Output -- Chip Select for HSPI
GPIO16 -- Output -- Disables Vpp generation

I went into the user_init() function and removed all the commented out code leaving an example of the PIN_FUNC_SELECT() macro. I then set GPIO_PIN0 – 15 registers to 0 which disables interrupts and disconnects the ΣΔ output.  I compiled the code and uploaded it and it crashed.  To find the new problem I caused, I commented out all the new code except setting the GPIO registers to 0. I rebuilt and uploaded the code and … a continuous stream of reboots.  I commented out setting the GPIO registers to 0 then put the PIN_FUNC_SELECT() back in. And … reboots slowly.

I removed the function selects that should be controlled by the API anyhow(GPIO6-11). And … I found a typo on the GPIO6 function select. I fixed the typo, rebuilt, uploaded and it ran at least as well as last week.  I then started testing to see if it fixed the ΣΔ issue. The reset problem still exists.

Next I set a subset of the GPIO registers to a value of 0  I decided to go with the first 8 to see what would happen. Same failure, a stream of reboots. Then I noticed I wasn’t writing to the correct register locations.   I fixed this and then recompiled, uploaded, and code is running, but ΣΔ is still causing a reboot if i set the prescaler to greater than 99.

Next I started looking at the ΣΔ interrupt structure.  Unfortunately it has very little documentation that I have found so far.  I used google to search for articles pertaining to the use of the Sigma Delta and found very little.  My next step is to do a little experimentation. I decided to disable the ΣΔ while changing the prescaler.  I got the same results.  It’s time to make a Hello World program for a sanity check. It would be the minimum to set up and test functionality of the ΣΔ on GPIO4.  If it works correctly, then I have to take a deeper look at my code, if it doesn’t, I’ll have something to post to Espressif’s forum for help.

Have you had similar problems with a chip you have never used before?  I have uploaded the current code to GitHub. Use the link at the top of the right hand column to get the download.

Sigma Delta still causing resets.

When I first built this revision of PCB, the board would reboot a lot.  That turned out to be the mis-wiring of the SPI RAM.  Part of that process in trouble shooting that board, I had guessed that I had a noisy power connection to the Wi-Fi module. So one thing that I had tried was adding a large reservoir capacitor and a small filter capacitor near the power pins of the module. Unless I am drawing too much current from the voltage regulator, this should eliminate any possible power issues.

This means my first test is to measure how much current is being drawn from the voltage regulator.  To do that I removed the jumper that bypassed the lithium cell charger and attached 3.7V to the PCB from a bench power supply.  To do this I removed all the test pins I had soldered to the module and soldered one to +BATT and another one to GND.  I connected my meter in series with the power supply and turned it all back on.  I measured the current consumed between 75 and 80 mA for the whole range of 0 to 99 prescaler.  This measurement was made with the radio inactive.

I think I can rule out the power supply as my problem.  Next I decided to change the software to take steps of 10 instead of 1 for adjusting the prescaler.  If the failure is because of an accumulated error, this should happen later and I should be able to get a number larger than 100 without a failure. I re-soldered the  bypass of the Lithium Cell charger and uploaded the change. I got to 91 No Failure. At 101 it still failed.  I change the step to 30 and when I got to 120, I got a reset cause:2. (maybe there is a clue here, This means external reset.)  I found this in the 2c-ESP8266_SDK_Programming Guide.pdf file from the Espressif BBS.

There are two pins on the module that can be used for external reset.  Since the serial to usb bridge is controlling the reset line, I decided to look into the EN pin first. It looked good with the right resistor in place to pull it up.  I then started looking through the code to make sure the Sigma Delta was configured to the correct pin.  Turns out that it wasn’t configured to output on any pin.  There was a missing statement in the code setting pin4 to output the sigma delta channel.  I added that line back in, saved, recompiled, uploaded and tested again. It still is failing.

Going back to the external reset, I decided to put lower value pullup resistors on the reset lines. I changed them from 10 K to 1 K.  This should reduce any affect of noise on the pins and still not draw too much current when pulled low. It still fails in the same way.  I have another project where the sigma delta is working very well.  The main difference I can see is that on this project I am reading the sigma delta twice before I write to it. In my other project, it reads the register once.  So I am going to make a simple uint8 variable to retain the value I am writing to the Sigma Delta prescaler.

It is still not fixed.  Have you seen this problem? Have you solved it?



HSPI Frustrations

I cut the traces going to the SPI RAM that I figured out were wrong last week. On the PCB at U3 Pin3, and Pin5 I cut one trace each and on Pin6 I cut two traces.  Most of these cuts are under the chip so I made them before re-soldering the chip to the board.  Of course then I added wire jumpers to route the signals to match the schematic. I then added pins to connect the logic analyzer to.

Cut traces Chip Installed Rewired SPI





Last week I was looking at the the SPI driver code by MetalPhreak on Github as well as his blog to figure out how to send commands and data out and receive back over SPI.  The register SPI_USER is used to configure the SPI, SPI_USER1 sets up data length, SPI_USER2 sets up the command length and Command data.  Additionally, there is an SPI_Address Register that I can use to select an address in the RAM. Finally SPI_W0 to SPI_W15 are the data packet working registers — This is where I will put my “Hello World”.  I can write or read up to sixteen 4 byte words.  My RAM is organized in bytes so I will be putting bytes of data into the working registers.

So for initial setup I think the following should work for writing data.




The following should work for reading data:



The CS_SETUP and CS_HOLD parameters affect chip select timing. Setup is before clocking out data, hold is after.  Some chips need extra set up or hold time.  It will not affect performance significantly so I just turned each on by default so I don’t have to wonder if this RAM chip needs them. USR_COMMAND tells it to send the data in the command register. Likewise USR tells it to send the data in the Address Register.  USR_MOSI tells the hardware that there is data in the Working registers to be sent out. USR_MISO tells the hardware that I want to receive data into the working registers.

For the SPI RAM I want to send a command(Write), An Address(0), and 12 Bytes of data(“Hello World”).  This totals 16 bytes of data to be sent on the SPI bus:

1 byte for the command: 0x02
3 bytes for the address: 0x000000 and
12 bytes of data: “Hello World” including 1 trailing NULL.

For my first attempt to write to RAM I chose to hard code the instructions.
In my SPIRam.c File I had already created a function called writeRam.  I deleted it’s contents, and added the stuff to make this work.
void writeRam(char data[], int length){


((7&SPI_USR_MISO_BITLEN)<<SPI_USR_MISO_BITLEN_S)| //Ignored for write
((23&SPI_USR_ADDR_BITLEN)<<SPI_USR_ADDR_BITLEN_S)); //address is 24 bits A0-A8

WRITE_PERI_REG(SPI_ADDR(HSPI),(uint32) 0x000000<<(32-24)); //write 24-bit address

(((7&SPI_USR_COMMAND_BITLEN)<<SPI_USR_COMMAND_BITLEN_S) | 0x02)); // Write Command

WRITE_PERI_REG(SPI_W0(HSPI),0x48656C6C); //"Hell"
WRITE_PERI_REG(SPI_W1(HSPI),0x6F20576F); //"o Wo"

SET_PERI_REG_MASK(SPI_CMD(HSPI), SPI_USR);// Tell hardware to do it.

After fixing my typos, I compiled and loaded the code.  The system booted without hanging. then I hooked up the logic analyzer to look for the data being transferred and it didn’t work. The Chip select line(U3 Pin1 ) doesn’t go low for a frame of data.  This means the chip never gets selected to write to.

With several hours of tinkering, I finally have it close, but it is still not working correctly.  The CS0 pin is being activated when the HSPI CS pin is being activated.  So I am getting the correct sequence of bytes when HSPI CS is low, but CS0 is low at the same time.

HSPI almost working

I have not posted a new copy of the software, I don’t believe it is useful to anyone yet.  It isn’t even useful to learn from.

Have you had similar frustrations? Have you gotten the HSPI to work in overlap mode?

Please leave a comment below.


ESP-12E pinout differences

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) — ?

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.

SPI Pinout FixESP-12F

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


I started out this week by hooking the SPI RAM to the logic analyzer. Then I hooked up the USB cable and it was stuck in a reboot cycle. I set the flash speed back to 20. Still stuck in reboot cycle. I disconnected the logic analyzer still in reboot loop.  I commented out the initSpiRam function in the startup code still stuck in reboot loop. This leads me to believe I have a power supply problem.

If it’s a power problem, adding large (100 μF) and small (0.01 μF) capacitors around the ESP-12E would solve the problem.  The 100 μF capacitor will act as an energy reservoir. The small capacitor will act as a noise filter. I piggy backed both a 100 μF and  a 0.01 μF capacitor on top of C4 the decoupling capacitor for the ESP-12E module. This didn’t solve the problem.  Next I suspected the SPI RAM was the problem.

I probed CS0 along with the SPI RAM CS line and they were in perfect phase.  This means that Q6 is not inverting the signal. This results with U2 on the SPI bus while the flash is being accessed.  That would definitely get it stuck in a reboot loop.  After feeling stumped for a while, I replaced Q6. It booted normally again. I uncommented the initSpiRam function and it started rebooting again. I tried with and without initSpiRam being called and it would consistently reboot when initSpiRam was called.

With initSpiRam uncommented, I went into the function and started commenting out lines to see what was causing the reboot.  It appears that ENABLE_SPI_DEV_CS() is causing the reboots. I moved it to after spi_master_init to see if that would work. spi_master_init(HSPI) by itself works. Next I tried adding overlap mode. It appears that overlap has to be after master init.  The SPI driver files and headers don’t have any way to read back data while in SPI master mode.

I decided to do a very simple test. I would do a SPI Master Write without overlap mode turned on. One write of one byte immediately after boot so it would be easy to catch on the logic analyzer.  The HSPI pins are:

GPIO14: CLK  Pin 5
GPIO12: MISO Pin 6
GPIO13: MOSI Pin 7
GPIO15: !CS  Pin 16

Chip select is the same pin I am already using, the rest are unconnected. I put a jumper across Q6 to always disable U2 by pulling CS (pin 1) high. I also soldered test points to each pin so I could easily attach the logic analyzer. With the jumper across Q6 I couldn’t even program the board!  This doesn’t make sense, I’ll have to come back to that.  I think I have some mis-wiring. I removed U2 from the board, and this allowed me to reprogram the PCB.

It now boots but doesn’t give me a menu. It appears to hang on the spi_mast_byte_write() call.

This is not a big deal, I haven’t set the SPI port.

All that time spent fighting this problem, and it turned out to be a solder bridge between R27 and a PCB trace from FLASH CS0.  I cleaned up this bridge and it started working reliably.

Finally I tested the basic HSPI write function. It didn’t work. but code is running without freezing or rebooting.  So I added a call to spi_master_init() still not working, no data on lines.  Looking in spi.c, I saw that spi_master_init() doesn’t assign pins to the HSPI port.  I added the lines below to user_init(). HSPI_PIN is defined as 2.


And I saw a byte on the logic analyzer. Yeah! progress.

SPI Byte outThe data speed is at 20MHz. I tried two writes in a row and got a chip select active for each write, and inactive in between. I need to figure out how to change this behavior, the SPI RAM commands always follow the falling(going active) edge of chip select. To write data to the RAM, I have to send more than one byte while chip select is active.

How do you do troubleshooting? Have you gotten HSPI Working on the ESP-12E? Does anyone know if there are different pinouts for the ESP-12E? Something I saw suggested to me that I still have the SPI RAM connected wrong again.

New PCBs

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

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 version: 8 2015 14:45:58)
SDK version:1.3.0
Ai-Thinker Technology Co.,Ltd.
Build: 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.



I am anticipating the new PCBs coming in soon, (I have a tracking number but it doesn’t show up with Hong Kong Post or USPS). In light of this, I decided to do a little research on the SPI RAM so that when it gets here, I can quickly write code to test the functionality of the design.  The SPI RAM I have chosen is a 23LC1024.  A common manufacturer of this chip is MicroChip, I downloaded their datasheet for this chip and started looking at the process to write to and read from the RAM.

Notes for writing to SPI RAM:

Maximum 20 Mhz Clock for all data transfers (might cause me to slow down the FLASH)

Write speed only limited by clock speed.

Write command(0x02) followed by 24bit address followed by data

Page Mode 32bytes before sending a new address

Sequential mode can fill the whole RAM

Write is terminated by CS going inactive(HIGH)

Notes for reading from RAM

Same maximum clock speed.

read only limited by clock speed.

Read command(0x03) followed by 24bit address start receiving/clocking data from RAM

Three modes of operation, Byte, Page, and Sequential.

Byte mode only allows reading/writing one byte before having to resend an address.

Page mode all data is accessed in pages of thirty two bytes. Not very useful for this project.

Sequential mode allows access to all of RAM as one big block that I can start accessing from any point. I need to set the mode register bits 7 and 6 to 01.

I am going to start in standard SPI mode, Make sure it is working then adjust the code to start taking advantage of the SQI interface.

Preparing for fabrication and population Hardware V00F

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.

V00FDcartI 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)

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?