I bought the DIY KIT at seeedstudio recently, as I needed to feed my soldering obsession. Here are some images of the KIT coming right out of the box:
I had to use my milling machine, because the front panel cutout for the LCD was too small. Oh and DON’T UPDATE to firmware -080. It completely borked my scope. Also the 10pin header for programming is NOT ISP compatible, the layout is different! Consult the manual and make an adapter to standard 10pin ISP. Currently plugging in a normal programmer with short 5V to GND.
The original fuses for the ATmega64 were:
avrdude -c usbtiny -p m64 -v
- LFUSE: 0xAE
- HFUSE: 0xC0
- EFUSE: 0xFF
Doing some research with a fuse calculator showed that the EEPROM is preserved during chip erase. Maye the confusion comes from there, so I changed the HFUSE to enable erase.
avrdude -c usbtiny -p m64 -U lfuse:w:0xAE:m -U hfuse:w:0xC8:m -U efuse:w:0xFF:m
- LFUSE: 0xAE
- HFUSE: 0xC8
- EFUSE: 0xFF
To flash a new firmware (beware of this) use:
avrdude -c usbtiny -p m64 -U flash:w:113-06201-070.hex
…agonizing hours later…
It seems that the scope writes _important_ data to its eeprom and gets confused if that isn’t there or somehow wrong or incompatible. The timebase settings are among that. According to the manual one needs to flash 3 files to the device to fully program it.
- firmware ( available on jyetech website )
- bootloader ( nowhere to be found )
- eeprom data ( nowhere to be found )
I’ve contacted jyetech and hope they will make all files available. Why would they provide firmware hexfiles so people can brick their scopes ? GIVE US THE DAMN FILES !
I got an email from jyetech with the latest bootloader hexfile and the matching eeprom data for the current -080 firmware.
avrdude -c usbtiny -p m64 -U lfuse:w:0xAE:m -U hfuse:w:0xC0:m -U efuse:w:0xFF:m
avrdude -c usbtiny -p m64 -U eeprom:w:113-06201-080.eep -B 100
avrdude -c usbtiny -p m64 -U flash:w:113-06202-020.hex
avrdude -c usbtiny -p m64 -D -U flash:w:113-06201-080.hex
- Line 1: restore fuses, EESAVE is programmed to keep eeprom data at chip erase
- Line 2: flash eeprom data matching the 080 firmware, -B 100 because of timeouts
- Line 3: flash latest bootloader, full chip erase ( eeprom excluded due to EESAVE fuse )
- Line 4: flash firmware, use -D to skip chip erase and keep the bootloader intact
… guess what: even later …
I’ve added a 4pin header to the scope to get access to the TTL level serial port. The new 080 firmware supports sending screens to a PC, so I wanted to test that. Unfortunately it doesn’t just push out the data in some sort of CSV list, but it requires a protocol and detects if the listener doesn’t reply with the right code. Bummer. I also wanted to test uploading a new firmware with the onboard bootloader. The program to upload is called “avrubd” and can be downloaded from jyetech.com as well as the latest firmware. Unfortunately the upload software is windows only and does not run with WINE on linux.
Some more thoughts on what might lead to the strange behaviour of the 080 firmware. I’m using a 9V AC wall wart to power the scope right now. It is not regulated as it spits out about 13V without load. The scope has a built in full wave rectifier and a 7805 5V voltage regulator + capacitor. I haven’t used my “real” scope to check if there is significant amount of ripple or other noise left which might upset the ATmega64. I’ll have to use a regulated bench power supply to test if I can get the scope to crash with that as well.
A few improvements for the scope would be:
Use a standard 10pin ICSP header, so one doesn’t plug in a programmer and wonders why all the programmer’s lights go out due to over current. Right now a standard 10pin plug will short 5V to GND. Also a standard header would allow to use a simple jumper to reset the CPU by connecting pin5 (reset) to pin6 (GND). Right now pin6 is not connected. This could be hacked of course, but only _before_ the LCD has been assembled. Add a cutout on the back panel to allow access to the header. Right now the back panel has to be removed to plug in the 4pin serial plug. 90° headers would be an option, but that doesn’t look very clean. Also things like that get bent and break off all to easily.
Here’s my latest post on the arduino/seeedstudio forum with important news:
New information on the firmware update !
As of NOW jyetech provides these files on their website
- eeprom data
If you want to update the firmware and have access to a windows PC, download the updater and update using the bootloader! It also works using a virtualized windows XP (e.g. using virtualbox) and an FTDI cable or a moderndevice BUB (tested) or the equivalent from seeedstudio. You will have to build an adapter cable to match the USB adapter pinout to the 4pin serial connector on the scope. You have to add the serial connector yourself, the parts are not included in the DIY KIT.
Please note that once you have updated and decide to downgrade the firmware, the eeprom data won’t match anymore and you may get odd behaviour!
If you are on LINUX/MAC using a programmer and avrdude seems the only option right now, unless someone finds a way to talk to the bootloader with avrdude directly. The avrdude commands are describes a few posts earlier.
According to seeedstudio the front panel size mismatch is being addressed.
I’ll further investigate if the problems I have with the new firmware might be caused by a bad (unregulated) power supply I’m using right now. Maybe some changes in the firmware use tighter timing settings and make it prone to noise on the supply lines.
I’ve been able to make it crash with the 070 firmware and a clean power supply. I’ve checked with my big scope that the ADC chip doesn’t get any clock signal form the ATmega64 anymore when it is crashed. That could explain why the screen shows nothing anymore or at least doesn’t get any updates. I’ve also confirmed that the CPU is only rated up to 16MHz (ATmega64-16AU) but it is clocked with 20MHz in the scope. Maybe this one doesn’t tolerate 20MHz and gets upset.
To make sure it’s not caused by bad solder joints, I’ve touched up all the pins of the ATmega and the ADC chip, but that didn’t improve things at all. I will make one last attempt to fix it by replacing the CPU hoping it works. If that doesn’t help I will salvage some parts (display, switches, ADC) and the rest will go into the TRASH.
>> http://groups.google.com/group/jye-tech-oscilloscopes <<