Previously Working Shruthi No Longer Boots

Some years back I assembled and have since been using a Shruthi from full kit components. I had put it away for at least a year (working on other hobbies), and came back around to use it a couple weeks ago, only to find that it no longer boots up. I’d never had a single problem with it when it was working, so I’m a little confused as to what may have gone wrong. I’m even using the same 9v power supply that it was working with before, as well as trying a couple others I had lying around.

The only activity I see on the control board is the display backlight and LED 8 is lit constantly. From other forum troubleshooting threads I’ve seen people discussing problems with the two logic ICs on the control board (165 and 595) being installed incorrectly during builds, but that’s not my problem obviously since my unit was working just fine before. They aren’t socketed by the way.

I’ve checked that the control board is receiving 5v from the filterboard, and I also even tried to put in a ATMega from another kit I hadn’t yet assembled, but no luck.

I will mention that one thing I did before plugging it in for the first time in months was to change out the EEPROM chip for a 512Kb unit as the kit part I received from way back was only 64Kb. I was looking forward to pulling down all the new preinstalled patches and updating the firmware before I got back into using it. I’m fairly certain from what I know about the design that simply putting in a blank EEPROM wouldn’t cause any damage.

Is my crystal maybe dead? Caps near the crystal? It seems that a lot of boot failures are directly related to crystal problems if it’s not the two logic ICs. Maybe one of my ICs is toast for whatever reason. I sure wish I had sockets on them.

Any help is greatly appreciated.


Since the only thing you changed, was swapping out the EEPROM, I would concentrate on this first.
Is this the right type of EEPROM? Is it put in the right way round?

I forgot to mention that I swapped the original EEPROM back in when it wouldn’t boot. I also should mention that I reflowed all the solder joints for the two ICs, the quartz, and the caps.

I should also add that the EEPROM I used was one of the same as specified in the current BOM, so I have a hard time believing that it might have done anything to cause the current problem.

What kind of filterboard do you have? If the crystal was working fine i don’t think it’s that. Could it be that you somehow caused a short while changing the EEPROM? Do you have any leds switching one?

It’s an SMR4. I highly doubt I shorted anything considering it’s in a case with all the proper spacers and I pulled the control board off to do the install. I’ve also tried powering the control board directly with 5v with no luck.

As I said, only LED 8 comes on.

One new item to note: I tried cranking the contrast up and now realize that the top row of the display is a solid line of blocks. I recall seeing some troubleshooting for that type of response.

After looking up the LCD issue in the wiki, that also doesn’t describe my problem. I’m not even getting past boot on my unit since there’s no response from any of the controls whatsoever, only LED 8 lit as I stated before.

did you install an OLED display? Did you flash the atmel yourself? It could be the bootloader is not current. If you answered yes to anything above, try pulling the power from the Shruthi in and out a couple of times. It should boot eventually.

Everything is stock from what I received in the kit some years ago. Preprogrammed atmel that came with said kit. From what I recall, still running 0.92 firmware.

Still no boot with attempting the power-on/power-off cycle. I had another full kit that’s not assembled, and I tried swapping in the atmel from that one as well, and it doesn’t boot.

Could be a cold solder joint in the atmel socket.

Have you checked voltages? Could you try powering it up without the filter board attached (using female breadboard jumpers)? Try swapping the 595 and 165 chips with known good ones?

More info to report. I’ve got an AVRISP II, so I figured I’d give a try at doing some simple communication with the atmel. I hooked it up to the AVR header, powered the control board with 5v disconnected from the filterboard and sent the following command:

avrdude -c avrisp2 -p m644p

This give me the following error:

avrdude: stk500v2_command(): command failed
avrdude: stk500v2_program_enable(): bad AVRISPmkII connection status: MOSI fail, SCK fail
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override this check.

From what I’ve read, this should have simply probed the atmel for some basic info and reported something useful back. If I’m getting a MOSI/SCK fail, then it isn’t even communicating correctly with the atmel, correct? Shouldn’t this work regardless of any other chip failures on the board, or is programming/communicating with the atmel dependent on the two ICs as well?

What voltages should I be checking on the control board?

I could cut the current 595 and 165 chips off the board and solder on the unused kit parts, but I’d really rather get some sockets on there first if this is going to possibly be a recurring problem.

Communicating with the Atmega is not dependent on the 165 or 595, but the 165 IS connected to at least two of the pins of the AVR header, so I suppose it could disrupt that if it is shot. Since all problems with only LED 8 ON are related to the 595 and 165, I really suggest swapping those out. It’s very easy to cause a short between the control board and the voltage regulators, and that will fry the 165 and/or 595. The only voltage on the control board is 5V but it’s hard to do measurements because a lot of it are digital signals, you need a scope or logic analyzer to make much sense of it.

Basically the atmel isn’t booting. How are you powering the board? The AVRISP MKII won’t power it. You’ll need to power it from another source.

I think the 1st thing you absolutely need to verify is the voltages on the filter board, then plug in the control board and check 5V. All of the power points are documented in the Shruthi build thread.

Once you’ve verified all of the voltages, then you can start looking around at other things. You said you have another Shruthi? Have you tried inserting the bad ones atmel in it to see if it boots? Remove the 165 & 595 and try. Before you put new ones in though, solder in sockets.

@qp, I appreciate the assistance, but as I stated, I’m powering the control board on its own from a 5VDC power supply to remove any possible issues that the filterboard might introduce. But I have checked the 5V supply from the filterboard, and it’s working as it should. I realize the ARVISP won’t supply power.

@ByteFrenzy, I was really trying to avoid replacing these chips as mine are soldered in. Since I have a full kit w/ SMR4 board, I may just steal some sockets from that kit and replace them later when I do the build. I’ll have to order another 165 and 595 anyway as soon as I destroy these by cutting them off the board.

One thing I noted in doing some continuity testing was that there’s continuity between MOSI and SCK pins. I wasn’t sure if that’s normal or not. I don’t know enough about the atmel architecture to know.

I went through every pin on the atmel and probed the leg on the chip to the pad on the board, making sure to avoid touching the leg from the socket itself to be sure I had good continuity between the atmel and the board. They all check out.

I’m starting to lean toward a fried 165 or 595 from everything I’ve read and the information I’ve received from all of you. Parts are cheap. I’ll hack the chips out one at a time and replace them…putting in some sockets while I’m at it.

Time to pull out the desoldering gear. Hooray…

There shouldn’t be a connection between MOSI and SCK. If there is no solder bridge on the ISP connector (the only place where these signals use adjacent pins) then it’s most likely a bad 74HC595.

Yeah, I just remembered that I also put on a new angled header for the ARV programmer spot, but I see no bridges there. I was concerned about that myself when I found that those two pins had continuity. I’m guessing that until I rectify that short, that’s likely the problem.

@cj55, can the 595 being internally shorted (blown) cause those two pins to appear bridged?

I just replaced the 165 and socketed it. No change, obviously since with this new information, that was not my problem. Oh well. Got to practice my desoldering.

Wow…it’s just getting worse. I was double checking the connection on the new header to be absolutely positive there were no bridges, then just decided to remove it altogether, clean up the vias and pad to be really sure it wasn’t that, and now when powering on I get no LEDs at all. Most of the time no initial all-LED flash, but sometimes all do briefly flash upon power, but none stay lit. Then I had once where only LED 5 was lit, but no response. Haven’t been able to repeat that and LED 8 is nowhere to be found on any attempt.

This is not the direction I was hoping to be moving. If somebody tells me the 595 being dead can do all this I will happily replace it at this point. I just don’t want to go further down this hole making things worse along the way.

I think I need to quit for the day. See if anyone has some sage advice to throw my way before I dig at this more. So frustrating. I was really proud of building this thing and having it work perfectly on my first try. Now I’m not sure what I’ve done to break it so badly.

It would help a lot to have high resolution images of the top and bottom side of the board.

Regarding your LEDs: 74HC165 that you swapped is only for the Inputs (buttons) whereas the 74hc595 drives the LEDs. Weird behaviour on one of those can surely cause all kinds of random LED activity. One thing to note is that their outputs remain undefined until they receive a valid byte from the atmel. So with a dead atmel you could basically get totally random LED output as well.

Here’s how I would proceed: First, try to get a sign of live from the atmel. Is it in a socket? If so, take it out and try to put it on a breadboard. You will also need a crystal (anything from 8 to 20MHz should be fine) and its two caps, and the ISP header with the resistor from reset to +5V. Try searching for a atmega644p minimal example on Google - or ask here if you are not sure what to do.
Once the atmel is on the breadboard and properly connected to the rest of the above components, try that ISP command again and see if it is okay this time.

If you don’t have the components for the breadboard test or if your atmel is not in a socket, here is an alternative approach using the control board:
To find out, if the atmel is alive, you should first remove any sources of uncertainty and anything that might interfere with the communication to the atmel. Remove the 74HC165 and - if you are confident about the desoldering - the 595 as well. Try to probe for continuity between MOSI and GND as well as MOSI and 5V. Try the same with MISO, SCK and RESET. If there is no continuity from any of those to either of the supplies, you should be able to get an answer from the atmel.

In a nutshell: This is what could make an atmel appear dead:

  • missing 5V supply

  • a short or other interference on RESET, MISO, MOSI or SCK -> check soldering and remove 165 & 595

  • a bad connection to the crystal or one of its caps -> check soldering

  • a broken crystal

  • a defective ISP adapter (unlikely)


Not to discount anyone else’s recommendations, but this is probably the most helpful thing I’ve been given so far.

I was able to find some info on breadboarding the atmel (or at least an ATMEGA chip of a variety), and after a little trial and error I was able to get communication with it. I even successfully updated the firmware and bootloader on the chip. So at least I know that’s working. I got a clock and the rest of the parts from the other unassembled kit.

I removed both ICs, soldered sockets on, and stole new 165 and 595 from the other kit. I tested all the continuity checks you recommended (without the ICs in place), and there’s no continuity of these pins with 5V or GND.

I put the new chips back and tried to power it up, and still nothing. I also tried simply powering the board with and without the ICs in place and communicating through the header. When I power the board, I get a green light on the AVRISP2, but then attempting to do a simple probe, I still get the MOSI, SCK fail.

Could this all be due to a bad quartz or caps? I checked all the solder joints and actually reflowed all of them to be sure.

Whoa! Okay, so I just posted the last comment, and I’m sitting here with the board plugged into a standalone 5V supply. It was sitting on the desk upside down.

I turn it over and find the control screen is up! It apparently just took forever to boot maybe? So does this mean it’s a bad quartz or the caps on the quartz? Is the ATMEGA defaulting to some horrendously low clock speed?

I’ve got the spare parts to swap if somebody can confirm this is typical behavior on a bad quartz circuit.