Troubleshooting MIDIpal build

#1

Well… it seems I will never advance beyond being a monkey poking holes with a stick… My MIDIpal build has caused much anguish, tearing of hair and gnashing of teeth and I’m hoping someone (Pichenettes?! anyone!?) can help me troubleshoot. I should add that I managed to successfully build a SammichFM with little problem so am not a complete SMD virgin however, SMD soldering most certainly is not easy.

Terrible things that happened during the build:

  1. Melted the contact off one end of C1 (100n SMT cap) - have ‘patched’ it and soldered in place but can’t tell what it is for (MIDI optocoupler?) or if it is working.
  2. Disaster #1: accidentally plugged in a 12V supply instead of the other 9V one sitting on my desk = blown zener diode - replaced zener’s with non-SMT parts and all is working again, BAD = lifted pads from desoldering :frowning: GOOD = 3.3V from the regulator still :slight_smile:
  3. Disaster #2: bought this cheap USBasp based programmer: ebay USBasp programmer and being an AVR noob, didn’t check the output voltage. Plugged it in to the ISP header using mini patch cables that come with the Shruthi kits (to convert from 10 pin ISP to 6 pin). Tried programming the MCU and it appeared to work except for the error shown in the attached avrdude-report text file. Subsequently found a 0 ohm SMT resister on the USBasp programmer labelled ‘5V/3V3 SEL’ so de-soldered it and now get 3.3V at VCC from the programmer.
  4. Programming appears to work but the MIDIpal does not :frowning:

What happens:

  1. The screen comes on but only shows blank or black squares when adjusting the contrast pot.
  2. Holding down the encoder switch then powering on makes the LEDs flash green, red, green, red very quickly with the red LED remaining on until either power off or SW2 is pressed.
  3. Programming with AVRdude appears to work except for an error initially programming the efuse, details in the attached avrdude-report text file. I used the pre-built firmware downloadable from the M-I site. Reading back the efuse shows value=05 and not value=FD but I believe this is expected (see: * Extended: 0x05 )
  4. I have continuity tested the board and my soldering to the extreme and all appears good.
  5. Occasionally, the programmer reports the chip has not been identified properly (avrdude: Device signature = 0x000102 / avrdude: Expected signature for ATMEGA328P is 1E 95 0F / Double check chip, or use -F to override this check) however, re-running the avrdude command or rebooting the MIDIpal usually results in it reporting properly again.
  6. When programming, the green LED stays on and the red LED flashes to indicate progress of the firmware being uploaded. When the eeprom firmware is uploaded, the red LED is a lot fainter.

Questions:

  1. Why doesn’t it work? (crystal ball question!) - could it be the 12V that fried the zener or the 5V from the programmer? :-S
  2. Are there any diagnostics that I can do to check if either the screen is broken (an LCD hello world app) or to check if part of the MCU is dead?

Thanks for any and all help/criticism/ridicule.

#2

The overvoltage might have wrecked havoc ; to the MCU or to the LCD. It is not clear if the 5V / 3.3V sel controls the voltage applied on the VCC pin of the programmed circuit (bad) or just the logic levels (still not good, but better).

Things to try:

  • Remove the -V flag from the command line to enable the verify feature. Check if there are reported errors (corrupt flash?).
  • I have attached a .hex file which prints “Hello!” on the LCD and flashes the LEDs. If the LEDs flash but the screen doesn’t show anything, it’s a problem with the screen.
1 Like
#3

Thanks for your help Pichenettes.

Your test app seems to work except for the screen. The LEDs flash alternately red and green. The verify when flashing the firmware threw an error first time round but on the second flash it was successful. I need a new screen it seems.

#4

You should probably get a new C1 as well, I would be amazed if that cap is still alive and kicking, or whatever caps do. This has nothing to do with you programming the MCU though, as I understand it the C1 is used to filter the voltage driving the opto coupler in the MIDI input.

#5

If you have a scope, does the voltage at the 3.3V point appear to be stable? Or does it have ripples?

#6

I had another look at the problems today. I want to be absolutely certain that the screen is at fault before buying (and waiting) for a new one especially as they are one of the most expensive parts and apparently quite rare. Things just don’t seem to add up:

My friend’s scope confirmed my suspicions that the 3.3V is calmer than Mare Tranquillitatis. My PSU is a regulated 9V DC 400mA supply. Testing with a battery also shows a stable signal.

The Midipal schematic shows +5V VCC at the ISP header. Is that a typo Pichenettes? If not, then when I originally put +5V DC from the VCC pin on my USB programmer it should not have caused any problems?!

The 12V I originally, stupidly applied to the Midipal’s power socket, I have just realised, was 12V AC @ 1A :frowning: however, no more than 3.3V would have reached either the MCU or the LCD in this event surely?! I also neglected to add that a little smoke erupted shortly after connecting the 12V from the vicinity of the Shottky diodes and C2 polarised capacitor. One of the diodes subsequently was tested as faulty, the capacitors still charge (and don’t matter? see below).

My basic understanding of the electronics is this: 12V AC input would have been full wave rectified to around 16.8V DC by diodes D2 and D3. According to the diode spec sheet, they can tolerate a 30V reverse voltage maximum (though clearly one was faulty after checking). The ~16.8V DC would then have gone through the polarised capacitors and regulator. The spec sheet for these capacitors state they are rated for 16Vdc (20Vdc surge). My multimeter shows they still charge and anyway, isn’t it true that if the voltage is already regulated, these capacitors won’t do much? Also, the regulator is rated at 20V maximum and apparently still works because it is still outputting a stable 3.3V. (My basic knowledge remains just that - see my next post)

All in all it looks to me like nothing was damaged by the 12V mistake except one of the rectifier diodes. Actually, all parts associated with input power supply regulation were within tolerance. With my limited understanding of electronics, is my assessment of the situation correct?

With regards to connecting my 5V Vcc USB AVR programmer to the ISP header:
The MCU is rated at 5.5V maximum (which is perhaps why it still works when programming and running the test app).

Information regarding the LCD seems inconsistent:
The LCD spec sheet says 3.3V max.
This Newhaven forum entry says 5V should be fine (except for changing a resistor to limit backlight current - my backlight still works fine).
The SPLC780D driver spec sheet shows that it can operate from up to 7.0V maximum.
The alternate ST7066U driver spec sheet shows it can operate from up to 10.0V maximum.

To summarise:

How likely is it that the screen is faulty based on the information I have found?
Is there a way to measure voltages on the LCD output/data pins of the MCU that would indicate whether or not it was functioning correctly?
Would connecting up a Shruthi-1 LCD module help determine if the MCU is faulty? Would the code need re-written to support a larger LCD module?

Any advice appreciated. Please forgive my rather crude and perhaps slightly misguided understanding of the fine art :wink:

#7

I see now that the Shottky diodes are not for full wave rectifying but only polarity protection correction :S Bumbling fool alert!

1 Like
#8

> The Midipal schematic shows +5V VCC at the ISP header. Is that a typo Pichenettes? If not, then when I originally put +5V DC from the VCC pin on my USB programmer it should not have caused any problems?!

The pin 2 of the ISP connector is connectd to VCC, ie 3.3V. The +5V label is part of the stock ISP symbol, I cannot edit it.

> With regards to connecting my 5V Vcc USB AVR programmer to the ISP header: The MCU is rated at 5.5V maximum (which is perhaps why it still works when programming and running the test app).

Yes, you are correct regarding this.

> How likely is it that the screen is faulty based on the information I have found?

I don’t think it is the MCU. If you trust your soldering, I don’t see many other culprits beyond the LCD module.

You can try hooking up a 16x2 LCD module ; I think it’ll work (I did this when developing the firmware).

1 Like
#9

:’( boo hoo

The new screen hasn’t solved the problem. It is still just displaying black squares or nothing when adjusting the trimmer. The only thing remaining that could be causing the issue is the MCU I think. Strange that it runs the test program but won’t run the screen.

Can anyone confirm that the trimmer needs to be a few turns anticlockwise from the clockwise extremity to display text so the contrast is correct? I have tried turning the trimmer to both extremes. I have also replaced the trimmer, the damaged SMD capacitor and the two SMD Shottky diodes.

What would happen if the crystal was damaged? How can I test it?

Does anyone have any tips for removing the MCU without pulling traces and damaging pads?

#10

If the crystal was damaged the test app wouldn’t run.

Do you have a way of looking at what’s coming out of the LCD lines? are you sure you haven’t shorted any of those?

#11

I did check for shorts on all the LCD lines originally, I’ll check again and post here. I don’t have a scope unfortunately. Maybes I must get one!

#12

Anyone have a link to the test app that’s mentioned above? .hex file which prints “Hello!” on the LCD and flashes the LEDs.
Thanks