Tag Archives: Programmer

Schematic update

by

Arduino compass toy:

I have had a little time to play with the OLED panel this week. Unfortunately, I still can’t get it to work.  I have been trying to get it to work in SPI mode, But I think I now want to try to start working in either 8080 or 6800 modes.

Schematic Update:

I updated the schematic to reflect the results of my testing from 2 weeks ago.

I still need to try a high gain transistor in place of the one I used to see what will happen.

I am waiting to make some decisions before I update the schematic on GitHub.

Decisions:

Continue reading →

Update layout Hardware V00I

by

Finally time to update the layout.  The charging circuit works well and I changed the level shifter on the schematic last week. So this week, I updated the layout.

I started by generating a new netlist. Next, I ran CvPCB to verify all the parts had footprints associated with them. They all do. Next I ran PCBnew and imported the netlist; making sure the exchange footprint settins was set to change.  I got an error:

Error: Component 'U3' pad '~' not found in footprint 'Housings_SSOP:TSSOP-20_4.4x6.5mm_Pitch0.65mm'

I had to figure out what that means before moving on.  It suggest one of the pins was named wrong either in the schematic symbol or the footprint library. I checked the schematic symbol first. I noticed the GND pin didn’t have a pin number assigned to it. Easy fix, added it and updated the library. I set the GND pin number to 11, saved it to the library, made sure it was in the schematic correctly, and re-generated the netlist.  I had to delete it and re-place it into the schematic to correct the schematic.  This meant that CvPCB no longer knew the footprint to use, so I updated it and re-generated the netlist again. No more errors in PCBnew import of the netlist.

I started by ripping up the unconnected traces. Then I started placing footprints.  I hid the bottom layer to make it easier to see what I was working around on the top layer.  Once I had the parts placed, I started routing traces.  I had to adjust component placement a few times to get everything to fit.  As I got to a point that I couldn’t do all the traces on the top side of the board, I un-hid the bottom layer.  While I was working with both sides, I had to re-fill the zones several times to correct for the areas I added new traces on the bottom side.

I finally got to 0 unconnected nets. I did a quick look to make sure all the references were readable and not under other parts.

layoutv00i

I plotted out the Gerber files and did a quick check to see if it looked OK and got ready to order.  When I look at Gerbers, I am looking for broken traces and unintentionally connected traces.  I used Gerbview to do this check. As I went into Gerbview and tried to load the files, the were double of all the files.  It looks like the developers of KiCad decided to change the naming conventions  for output to gerber.  I went in and deleted all the files in that folder and re-ran the plots.  While looking at the gerber files, C10 and U3 references were covered up.  I went in and fixed them and re-plotted.  While I was at it, I discovered U10 wasn’t anywhere near it’s footprint.

I created a zip file with the plot files ready to upload to a fabrication house. I have uploaded the files to the github repository, click the hardware link in the right column to go get it.

Are you using Kicad?  What tools are you using to design in?  Do you have trouble finding datasheets for Chinese parts?

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.

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.

Programming Tools

by

Things don’t always go as planned.  The firmware upload tools did not work.  The recommended one for Linux is a python script called esptool.py.  I hacked on it to get it working, I bypassed some error checking to get it to work.  I don’t like this but it works for now.  I have tools that proved that the USB Serial port driver was receiving the correct values but esptool.py was not.

Disabling the error checking allowed me to get pre-compiled bin files loaded onto a NodeMCU Devkit Version 0.9 and then onto my circuit.  I downloaded the AT command set firmware as well as the NodeMCU Lua firmware and tested them with ESPlorer.  With the AT command set I was able to connect to my local network, open a webserver port and see a connect attempt from a browser on my Phone.  With the Lua firmware, I was able to turn on an LED on the Devkit PCB(GPIO0) and send some interrogation commands to my circuit.

With both firmwares, the software defaulted to 9600 baud.  This worked fine for my testing.  I have not yet figured out how to get software I create into the ESP-12E. I will be starting with the IOT demo to get a “hello world” project working. A key point will be to get software of my own design working and uploaded into the circuit.  At this point it doesn’t have to have any real functionality.

I also want to figure out why esptool.py did not work, and how I can make it more robust.  If I can solve this problem, I will submit my fixes to the github repository in hopes that it will help others.

There are some things that I discovered that will change the design.  I found a USB to UART bridge that costs less than a Dollar US; the CH340G.  The programming software controls the DTR and RTS lines to automate the re-boot and flash buttons, so I can get rid of the flash pushbutton and minimize the Reset into a couple of pads I can touch with a screwdriver.  Also, on the layout, I didn’t notice that OSHpark doesn’t do plated slots.  The USB micro connector layout has slots.  OSHpark drilled single small holes in place of the slots.  I had to modify the connector to make it fit in the holes.  I will change the connector layout to round holes that will fit the shell pins of the connector to solve this issue in future runs of the PCB.  There is a flare at the end of the connector that keeps it from laying flat, I will move the flare past the edge of the PCB so the connector can lay flat against the PCB. For strength I want to add a pad under the shell that will also be soldered to the shell. I broke the connector off during my testing.

Rev0APartialBuild

 

Change in Design

by

I changed my mind, I think the programmer should be able to be reprogramed without any special tools.  This means that the Microchip processor is getting removed and replaced with a USB to serial bridge.  I have decided on the Silicon Labs CP2104 USB to serial bridge. My decision is based on cost and minimal external components. I went to several suppliers and compared 1K quantity prices.  I also confirmed that I can used the built in USB VID and PID.

I followed the example circuit in the datasheet for the CP2104 making minimal connections for a self powered device.  Since I am going to eventually have a battery that is the correct mode to wire for.

Since I no longer have the Microchip processor to control the high voltage, I connected the SET line of the AAT1230 to GPIO15 of the ESP12E.  The pulldown on GPIO15 will keep the voltage regulator disabled during a reset and I will drive it low anytime I am not using it, minimizing the current it draws from the battery.

I connected the Feedback voltage from the high voltage and the target voltage divider into an analog SPDT switch(NC7SB3157 chip) and connected the common terminal to the ADC input of the ESP-12E.  This allows me to verify what voltage the target system is at and what Vpp voltage is maintained during programming.  I ran out of IO pins on the ESP-12E, so I am added an SPI port expander(MCP23S08).  I have to give up 1 pin for chip select but I gain 8 general purpose IO pins.  So I moved the data direction control pins to the port expander and then connect GPIO5 to the CS line of the port expander. I verified the port expander could operate at 3.3V to match my operating voltage.

I connected GPIO2 to the Switch select line of the analog switch.  A high selects the VPP voltage divider, a low selects the Target voltage divider.  The voltage dividers are necessary because I could be dealing with more than the 3.3 V that the ESP-12E can handle.

None of the new devices were in the libraries.  I had to create each of the MCP23S08, the CP2104, and the NC7SB3157 in the schematic library.  I still have to connect the Vpp line to the target connector where I can leave it high impedance, set it to high Voltage, or Ground it.

USB Bridge and Vpp Port expander and Analog switch

Associating parts to pinouts

by

I ran the annotate schematic tool, then ERC to look for obvious mistakes.

I got a bunch of errors because I had left pins unconnected.  This is a reminder that I have to make sure these pins are set to outputs later.  I marked each unconnected pin with a no connect marker and I am down to 3 errors. I replaced the battery connector with a battery symbol.  It didn’t get rid of the error, I will have to check this connection on the netlist.

I then ran the netlist tool with default settings.

Then I ran the CvPCB module of KiCAD. I assigned footprints to the parts from the schematic.  Most of these matched.  For resistors and capacitors, I chose to use 1206 SMD for the footprints.  There is no footprint for the ESP-12E.

I found a footprint online for the module, but KiCAD would not import it. So, I created a footprint and added it to the custom library for the project.

I chose the SW_PUSH_SMALL for the two tactile switches Reset and Upload.  These are through hole footprints, I am thinking I will copy this footprint to the custom library and modify it to go surface mount.

I have only done very simple layouts.  This will be quite a learning experience for me.

CvPCB 1st

Processor Option 2

by

The Microchip PIC32MX110F016B.

I went to Microchip’s website and worked through their parametric search tools.  I was looking for a device that could use the SPI interface at at least 10 Mbps and at the lowest cost.  There were no 8 bit parts that could meet the SPI requirement.  There were some 16 bit parts that could meet this requirement, but they were the high end parts.  I had to look into the datasheets to see the maximum SPI baud rate.  Since JTAG does not have 8 bit fixed width registers, I will probably have to play some tricks to use the standard SPI for JTAG operation.

Microchip PIC32MX110F016B

Device advantages

  • Two Fast SPI channels (1 for programming, 1 for data storage)
  • DMA transfers for each SPI channel– Frees software up to do data manipulation tasks
  • 5 V tolerant pins
  • I am familiar with Microchip and their IDE — MPLAB X
  • US $1.73 each in quantities of 100
  • Compatible upgrade path if this chip isn’t enough
  • Low pin count — 28 pins
  • Dip Part for prototyping

Device Disadvantages

  • I am unfamiliar with microchip 32 bit architecture
  • Limitations on free C compiler — mostly in optimization