IOT-Basisstation

This was my first attempt to design a PCB, and obviously I made quite a few mistakes. Lessons learned include:

• Check for zero airwires. The connection from the ISP reset header to the push button was accidentally left unrouted, and had to be bridged with 0.2mm enameled copper wire on the backside.
• Positioning the silkscreen. Bad mistake. I left all silkscreen print as defaulted by Eaglem and promptly confused two parts when soldering. Took quite some time to find the mistake.
• VCC headers would be helpful.
• JTAG headers are missing, and the Atmega1284P does not allow to debug by ISP via DebugWire.
• Check the footprint. First select the components, check the prices and the delivery status, and order, and only then complete the footprint layout. Micro-SD sockets are not all similar regarding footprint, and the push button also barely matched its footprint.
• DTR reset. Using the Arduino Ethernet libraries, it makes sense to remain compatible with the Arduino IDE deployment mechanism, which requires a header for the DTR line that connects to !RESET via a capacitor.
• GND→NC. In case someone notices the cutaway pins 38-42 of the W5500: Datasheets can change, and where these pins we declared as “must be tied to GND” in version 1.0, version 1.0.2 declares them “NC”. Tieing to GND would probably still work fine, though …
• SD-SPI. According to the SD card specification every SD card powers on in SD bus mode. However, we have to switch to the SPI bus mode. Worse: In SD bus mode the connectors of the SD card have different usage, and therefore any newly plugged in SD card (in SD bus mode) will disrupt both SPI communication with the W5500 as well as reprogramming via ISP.

Different from other open source approaches (Sowerbutts, Ariadne, Ethernut, Ethersex, and miscellaneous others at http://www.mikrocontroller.net), my bootloader obtains the application software not via TFTP from a local server, but rather via HTTP from any given server on the Internet. This allows remote deployment and software upgrade. Please note that the current bootloader is not resilient against MitM-Attacks etc.

How does it work? The Eeprom contains, in addition to a MAC address, also the URL of the boot server. Upon every reset the bootloader starts, retrieves new software from the boot server as necessary and programs it into flash memory, activates the watchdog, and starts the application software. Flash pages that did not change are not overwritten (in order to protect the flash lifetime in case of reboot loops). The application software must regularily feed the watchdog, otherwise a reset is triggered which reactivates the bootloader.

The bootloader can retrieve the startup IP addresses (own, gateway, DNS server) and the netmask either from the Eeprom as well, or via DHCP; the IP address of the boot server is retrieved via DNS.

The URL should contain a unique system id (hwid) as parameter, in order to allow the boot server to maintain a mapping between systems and their current application software, for instance via MqSQL/phpmyadmin (see screen dump). Within the URL the bootloader also transmits its own identifier (loaderid, composed from __FILE__ " " __DATE__ " " __TIME__) and the cause of the reset. The bootloader expects to receive an Intel_HEX file in the body of the reply to the HTTP GET request. It supports type 00, 01 and 02 records, which are exactly those produced by avr-gcc (Atmel Studio, Arduino).

The complete source code of the bootloader can be found at http://github.com/wangnick/httpboot.

The Internet boot server is a simple Python script in my case, connected to a MySQL database, and a file system containing application software in Intel HEX format. The boot server also registers and stores every boot request (in order to detect and debug reboot loops) in a dedicated database table.

• http://www.mikrocontroller.net/topic/313426
• http://www.mikrocontroller.net/topic/318844
• http://www.mikrocontroller.net/topic/323208
• http://www.mikrocontroller.net/topic/325077