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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | 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 ;-)