Gen7 ExtensionBoard USB A 1.0
Release status: experimental
Description | Part of Generation 7 Electronics
|
License | GPL v2
|
Author | |
Contributors | |
Based-on | [[]]
|
Categories | |
CAD Models | |
External Link | (none)
|
This is an extension board for Generation 7 Electronics providing an USB connection. It's based on an ATtiny45, running V-USB. Data transfer speed can theroretically reach the limit of the USB protocol, which is 1.5 MiB/s, equivalent to about 1'769'472 baud.
Status of development:
- The USB part works, sources are available in the Gen7 Github repository, instructions are below.
- The SPI connection to the ATmega doesn't work, yet.
- Development was postponed in favour of the B variant of this extension board.
Contents
Assembly Checks
- 0V on pin 4 of the ATtiny socket.
- 5V Standby on pin 8 of the ATtiny socket.
- 5V or less on any pin of the ATtiny socket.
Setup
This section shows how to set up this extension board. Some sub-sections may be done by the person you got your kit from, already.
Programming the ATtiny
This step requires a programming device and is only needed if your ATtiny didn't come preprogrammed.
Preparation
- Remove the ATmega from it's socket (ATmega and ATtiny share the same ICSP header, so to program one with an external programmer, you have to remove the other).
- Plug in the extension board. The USB connector shall end up closer to the ATX24 connector of the main Gen7 board.
- Do not plug in the USB cable.
- Plug the ATtiny into it's socket. Take care the groove on it's housing points towards the USB connector. Some ATtiny versions have a small hole instead of the groove, which should also point to the USB connector.
- Plug in your programming device (STK500, Parallel Port Programmer, prepared Arduino, whatever you have) into the main Gen7 board.
Now you can program the ATtiny with avrdude or an equivalent programming software.
Programming Fuses
This has to be done with some care, as mis-set fuses can brick the ATtiny. For example setting the chip's clock to an external clock disables any further operations.
A nice calculator for fuses can be found at Engbedded. Select the ATtiny from the menu, then check the following boxes and menus:
- PLL Clock
- Brown out detection level 4.3 V
- Serial program downloading (SPI) enabled
All other boxes should be unchecked. The result should be 0xE1 for the Low Fuse, 0xDC for the High Fuse. An ATtiny has no Extended Fuse. To program this, use:
avrdude -c ? # find your programmer, e.g. "avrispv2" avrdude -c <your programmer> -p attiny85 -P /dev/ttyACM0 -B 5 -U lfuse:w:OxE1:m -U hfuse:w:0xDC:m
NOTE: this is work in progress, it doesn't work that way, yet.
How to recover the Reset Pin
The pin count on the ATtiny45/85 is tight and to run the usb adapter as SPI slave we need a chip select pin. The only opportunity for this is to disable the Reset pin and use this pin as general I/O. The friendly folks at Atmel have even put a fuse bit into these ATtinys to do this switch, the RSTDISBL flag. The problem is, once this flag is set, a regular programmer can no longer program the chip.
The solution is to use a high voltage programmer. Community developments exist, of course. Some of the more simple types are even explicitely built with just restoring the fuse in mind:
How to program without a working Reset line
Under normal conditions, an ICSP programmer also operates the Reset line. To upload a firmware to a device, it checks the device singature, then pulls the Reset line low, then starts sending the bytes. After that, it releases the Reset line and the ATtiny starts running.
Just in case you don't have the Reset line connected, one can still upload a firmware:
- Connect the programmer as normal.
- Connect the Reset pin to GND manually.
- Use the same avrdude command as usual.
- Watch avrdude showing the usual progress bars. If no progress bar appears, the uploading doesn't work.
- After avrdude is finished, release the Reset pin.
That's it, the ATtiny should run normally now.
Troubleshooting USB
USB is made for fast data transfer, so demands on electrical signal quality is higher than with traditional serial devices. In case the device doesn't appear in your operating system, here are a few hints on debugging:
- Open a terminal and type "lsusb". This should show you the device. If the device is there, it's a fault of the operating system to not create the corresponding device file.
- If it's not there, type "dmesg". This always shows you messages. Messages like "device descriptor read/all, error -71" or "connect-debounce failed, port 3 disabled" hint to poor USB signals.
- Make sure the USB cable as well as the USB header housing is shielded, i.e. connected/soldered to GND.
- Maybe your Z-Diodes are too slow. The ones in the bill of material are verified to work; ones for high wattages are known to not work.
- You can try to remove the Z-Diodes entirely. This sends 5 V signals into 3.3 V ports, so it might break something. Yet, connecting with an USB hub in between not only protects your PC, but also raises the chances to get it working.
- A not calibrated internal clock also leads to poor signals and an only partly working device. Make sure your firmware actually does this calibration. One way to make sure is to enable USB_CFG_HAVE_MEASURE_FRAME_LENGTH and put this into usbconfig.h:
#ifndef __ASSEMBLER__ #include <avr/interrupt.h> // for sei() extern void calibrateOscillator(void); #endif #define USB_RESET_HOOK(resetStarts) if(!resetStarts){cli(); calibrateOscillator(); sei();}
- Another line in usbconfig.h shall help to recalibrate in regular intervals, to compensate for clock drifts due to warming or whatever:
#include "libs-device/osctune.h"
- Don't get frustrated. All the above has to work properly, it's easy to miss one of these. :-)
- This is a proper "dmesg" entry for the device, the numbers change from case to case:
[57594.152042] usb 6-1: new low-speed USB device number 52 using uhci_hcd [57594.310056] usb 6-1: config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing to Interrupt [57594.310064] usb 6-1: config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing to Interrupt [57594.334165] cdc_acm 6-1:1.0: ttyACM2: USB ACM device
Further Reading
Here are a few links into the net. These were picked up while developing this board.
- Programmer using ATtiny. This is one of the examples showing how to use our ATtiny as a programming device. The idea is to program the ATtiny once, then use the ATtiny to program the ATmega. This would make the bootloader on the ATmega obsolete.