Maybe you remember my last post about the Jyetech oscilloscope and it’s weird behaviour. Not all of them are strange, as the free replacement DIY KIT I received from them works fine. At that time I suspected a sick ATmega64 cpu and had all sorts of plans to detect what components might be bad.
Long story short, I scrapped all of it and just replaced the ATmega64. Using ChipQuik it was as easy as it should be, a no brainer.
Here’s a video:
I had already posted the update sequence using avrdude, but here it comes again. I used the 113-06201-080.hex firmware, 113-06201-080.eep eeprom data and 113-06202-020.hex bootloader files provided on the Jyetech homepage.
Testing if the chip is there:
avrdude -c usbtiny -pm64 -v
avrdude: Version 5.5, compiled on Jul 23 2009 at 18:35:18
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
System wide configuration file is "/opt/cross/etc/avrdude.conf"
User configuration file is "/home/robert/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/parport0
Using Programmer : usbtiny
AVR Part : ATMEGA64
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 4 20 64 0 no 2048 8 0 9000 9000 0xff 0xff
flash 33 6 128 0 yes 65536 256 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 4 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : USBtiny
Description : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude: programmer operation not supported
avrdude: Using SCK period of 10 usec
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9602
avrdude: safemode: lfuse reads as E1
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FD
avrdude: safemode: lfuse reads as E1
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Setting the correct fuses:
avrdude -c usbtiny -p m64 -U lfuse:w:0xAE:m -U hfuse:w:0xC0:m -U efuse:w:0xFF:m avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.02s avrdude: Device signature = 0x1e9602 avrdude: reading input file "0xAE" avrdude: writing lfuse (1 bytes): Writing | ################################################## | 100% 0.01s avrdude: 1 bytes of lfuse written avrdude: verifying lfuse memory against 0xAE: avrdude: load data lfuse data from input file 0xAE: avrdude: input file 0xAE contains 1 bytes avrdude: reading on-chip lfuse data: Reading | ################################################## | 100% 0.00s avrdude: verifying ... avrdude: 1 bytes of lfuse verified avrdude: reading input file "0xC0" avrdude: writing hfuse (1 bytes): Writing | ################################################## | 100% 0.02s avrdude: 1 bytes of hfuse written avrdude: verifying hfuse memory against 0xC0: avrdude: load data hfuse data from input file 0xC0: avrdude: input file 0xC0 contains 1 bytes avrdude: reading on-chip hfuse data: Reading | ################################################## | 100% 0.00s avrdude: verifying ... avrdude: 1 bytes of hfuse verified avrdude: reading input file "0xFF" avrdude: writing efuse (1 bytes): Writing | ################################################## | 100% 0.01s avrdude: 1 bytes of efuse written avrdude: verifying efuse memory against 0xFF: avrdude: load data efuse data from input file 0xFF: avrdude: input file 0xFF contains 1 bytes avrdude: reading on-chip efuse data: Reading | ################################################## | 100% 0.00s avrdude: verifying ... avrdude: 1 bytes of efuse verified avrdude: safemode: Fuses OK avrdude done. Thank you.
Writing the EEPROM data:
avrdude -c usbtiny -p m64 -U eeprom:w:113-06201-080.eep -B 100 avrdude: Setting SCK period to 100 usec avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.06s avrdude: Device signature = 0x1e9602 avrdude: reading input file "113-06201-080.eep" avrdude: input file 113-06201-080.eep auto detected as Intel Hex avrdude: writing eeprom (1737 bytes): Writing | ################################################## | 100% 69.71s avrdude: 1737 bytes of eeprom written avrdude: verifying eeprom memory against 113-06201-080.eep: avrdude: load data eeprom data from input file 113-06201-080.eep: avrdude: input file 113-06201-080.eep auto detected as Intel Hex avrdude: input file 113-06201-080.eep contains 1737 bytes avrdude: reading on-chip eeprom data: Reading | ################################################## | 100% 26.73s avrdude: verifying ... avrdude: 1737 bytes of eeprom verified avrdude: safemode: Fuses OK avrdude done. Thank you.
Writing the bootloader:
avrdude -c usbtiny -p m64 -U flash:w:113-06202-020.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9602
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "113-06202-020.hex"
avrdude: input file 113-06202-020.hex auto detected as Intel Hex
avrdude: writing flash (65532 bytes):
Writing | ################################################## | 100% 207.97s
avrdude: 65532 bytes of flash written
avrdude: verifying flash memory against 113-06202-020.hex:
avrdude: load data flash data from input file 113-06202-020.hex:
avrdude: input file 113-06202-020.hex auto detected as Intel Hex
avrdude: input file 113-06202-020.hex contains 65532 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 117.99s
avrdude: verifying ...
avrdude: 65532 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Writing the firmware:
avrdude -c usbtiny -p m64 -D -U flash:w:113-06201-080.hex avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9602 avrdude: reading input file "113-06201-080.hex" avrdude: input file 113-06201-080.hex auto detected as Intel Hex avrdude: writing flash (20132 bytes): Writing | ################################################## | 100% 56.50s avrdude: 20132 bytes of flash written avrdude: verifying flash memory against 113-06201-080.hex: avrdude: load data flash data from input file 113-06201-080.hex: avrdude: input file 113-06201-080.hex auto detected as Intel Hex avrdude: input file 113-06201-080.hex contains 20132 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 36.09s avrdude: verifying ... avrdude: 20132 bytes of flash verified avrdude: safemode: Fuses OK avrdude done. Thank you.
I’ve had it crash again, but it seemed to take a bit longer than usual. The current draw is still only 190mA and not 240mA like the other DIY KIT. 240mA should be normal according to Jyetech. Maybe next weekend or so I’ll compare the two scopes and see if this one crashes more often than the other one. If it is still not “fixed”, I think I’ll leave it like it is right now. It don’t feel like poking in there much more or hunting for power supply / decoupling problems anymore. I think I said that when it crashed the cpu didn’t feed any clock to the ADC anymore (damn indirect speech). This time the ADC kept working when it showed strange behaviour, so maybe that’s an improvement ? I don’t know.
Now I’ve got a possibly still good ATmega64 sitting here and I need a project for it ;-)
>> http://groups.google.com/group/jye-tech-oscilloscopes <<
Related posts:
Great video. I felt your frustration just watching the video, I felt like throwing something (I am surprised you didn’t)…
What type of solder are you using? It seems to have a very long working time. I would have expected the chip to be affixed when it moved on you.
For desoldering I used a low melt Bismuth alloy sold under the brand name ‘ChipQuik’. A small test set is very affordable and the alloy lasts quite a while, as you only need very little. The supplied flux runs out much faster. It stays liquid for several seconds because its thermal conductivity is very low. It keeps the heat. I’ve written a short review about it.
Regarding the scope. It seems that the latest firmware runs pretty well on it. It may be an old revision board (also the front panel cut-out was too small for the LCD) and maybe tight timings in the code made it run unreliably. I don’t care anymore ;-)