Gastric's MegaDrum build

[gastric]

Yes, I absolutely did. The directions work great and I was using MCT and my VST simultaneously until recently when I un-did the multi-port routing so I could test MCT directly connecting to MD. I have a totally unrelated issue where MCT doesn't communicate with my MD unless I specifically go into Options and change the MIDI IN/OUT in MCT each time and wanted to rule out the MIDI-OX multi-routing as the issue. Anyway, that's a completely separate topic/issu which I've logged here: viewtopic.php?p=8235#p8235

Anyway, the loop issue is actually generated by MIDI-OX itself automatically modifying routing when changing MIDI DEVICES from having ONLY MIDI-OUT configured as USB Audio Device, then adding in MIDI-IN as well. It automatically generates a port routing where it routes the USB Audio In to the Out, thus generating the loop. Disconnect that and everything works fine regarding the looping I was detecting. Steps to reproduce.

* Open MIDI-OX
* Click Options \ MIDI Devices
* De-select everything in MIDI Inputs
* Select just USB Audio Device in MIDI Outputs
* Click OK to save your changes
* Click View \ Port Routings
* Note the simple 1-to-1 port routing that exists
* Close Port Routings
* Click Options \ MIDI Devices
* Select just USB Audio Device in MIDI Inputs
* Click OK to save your changes
* Click View \ Port Routings
* Note USB Audio Device (Input Ports) is connected to USB Audio Device (Output Ports)
* Hit a trigger
* You get a perpetual stream of MIDI data via the loop

At least that's my take on it based on the fact if you break the routing in MIDI-OX between USB Audio Device In/Out everything appears to work fine.

When I updated firmware I simply had nothing selected in MIDI Device Inputs to negate any potential issues all together.

[gastric]

My latest adventure:

* Was experimenting with various settings on my MD, AllGainsLow, etc. for an hour or so, using MCT, blah blah
* Decided to downgrade to a previous firmware purely to regain full MCT compatibility.
* Powered MD off
* Powered on with left key
* Erased firmware (confirmed by LCD)
* Sent 20090427 firmware with MIDI-OX but LCD just sat there at "erased" and I saw no MIDI LED blinking (can't recall if it did during previous firmware uploads at this particular step)
* Waited a few minutes, nothing was visibly happening, LCD was still at "erased"
* Tried to send 20090427 again with MIDI-OX but LCD remained at "erased"
* Waited several minutes, again LCD remainded at "erased"
* Powered off MD
* Powered on MD
* I now have a completely blank LCD, buttons do nothing, MIDI LED never lights, I've tried powering on while holding buttons, LCD never shows anything

The only potentially unusual thing I was having issues with prior to all of this was with the HH pedal. It could see the VU moving on it's own, and lots of MIDI activity, and during this I could not use the left/right buttons to access the various parameters. However, I could use up/down to access drum map. The only way to gain access to the various parameters was to physically unplug the HH pedal from the input jacks. I was having issues setting high/low levels manually since my MD is racked and not immediately reachable from my drum throne. So I plugged/unplugged the jack from the back of the MD. It may have been unplugged during firmware update, but I cannot recall specifically. Anyway, the HH pedal is the only unusual behaviour I was seeing prior to attempting the firmware update and now having a seemingly dead MD.

Note the MD is seen by Windows as USB Audio Device. So PIC seems to be functional.

I've read a few other threads indicating this same problem and as best I can tell my bootlader has been lost. Fishing for speciific suggestions prior to trying out the programming cable I made for my V2.5 kit.

[gabriel1712]

* Powered MD off
* Powered on with left key
* Erased firmware (confirmed by LCD)
* Sent 20090427 firmware with MIDI-OX but LCD just sat there at "erased" and I saw no MIDI LED blinking (can't recall if it did during previous firmware uploads at this particular step)
* Waited a few minutes, nothing was visibly happening, LCD was still at "erased"
* Tried to send 20090427 again with MIDI-OX but LCD remained at "erased"
* Waited several minutes, again LCD remainded at "erased"

Sometime the firmware doesn't load/load properly.

* Powered off MD
* Powered on MD
* I now have a completely blank LCD, buttons do nothing, MIDI LED never lights, I've tried powering on while holding buttons, LCD never shows anything

Restart the WHOLE upload procedure, with erasing and all.

[gastric]

As soon as I woke up this morning it dawned on me what the real problem was with the HH pedal and firmware update issue. After screwing with MIDI-OX I left MD selected in the Input and Output and MIDI-OX created a loop by automatically routing the MD In to the Out as I've documented before. This is what happens when I do stuff late-night and my brain is only in 1st or 2nd gear max. I didn't remember to de-select the MD In prior to firmware update or to simply modify the MIDI-OX routing. Though I wouldn't expect that to hose the bootloader, assuming that's what happened. But I suppose a massive loop of firmware update data could do all sorts of fun to my poor little Atmega32.

Unfortunately there's no way for me to re-run the firmware update procedure as far as I can tell. Again, my LCD is completely blank (but has backlight). Buttons do nothing to affect the LCD display. I noticed that my power switch LED which I soldered to pin 1 + 2 of the LCD doesn't light, either.

I did try running the update procedure again anyway (set MD Out only in MID-OX, checked buffers, turned on MD with left button, etc.), but it did nothing. Without the LCD working I really have no way of knowing what's going on anyway.

As best I can tell it looks like I somehow hosed the bootloader, or damaged the Atmega32 with my looped SysEx for the firwmare update. Though the bootloader itself is supposed to be protected. I have two Atmega's and theoretically have a proper programming cable so I'll try that later today or tomorrow.

[dmitri]

I noticed that my power switch LED which I soldered to pin 1 + 2 of the LCD doesn't light, either.

Doesn't it look strange? There must be +5. I cannot remember any bootloader which can work without power.

[gastric]

According to my DMM I'm pulling 4.63V on pin 1 & 2 on the LCD. I'll try to make some time to review the other "blank LCD" threads to see what other values I can compare to your specs and questions. But I really do think I simply lost the bootloader, though I understand it shouldn't be possible.

[dmitri]

In that case your mentioning that a led connected to ground (pin 1 of LCD) and Vcc (pin 2 of LCD) doesn't light up is a bit misleading.

[gastric]

It may be misleading, but it's the truth. As to why it doesn't work I cannot say yet. But I get the same V at the LCD pins and the LED pins. And it was working before as far as I recall. I was actually going to disconnect the power switch LED anyway as the LCD backlighting is indicator enough of the MD being physically powered on. But I'd have liked it to stop working because I made it stop working.

[gastric]

As best I can tell the LED in the power button is simply dead. V is fine and I can connect a different LED to the posts for the power button LED and it works fine, so my conclusion is the LED is simply dead. Though I can't say why. Like I said, I was going to disconnect it at some point anyway, and I've physically done that at this point. However, it's odd that the LED simply died apparently during, or coincidentally I noticed it around the same time as, the firmware update issue. I'm dismissing the dead LED as a non-issue, but am keeping it in the back of my mind as a potential symptom of some other problem.

As far as my MD overall from the time it was working as it should and me apparently killing it by updating the firmware with a MIDI loop via MIDI-OX the only physical thing I did with the MD was use the buttons and power button to access the bootloader, and unplug/plug my HH pedal in. Otherwise physically it's been screwed into my rack just sitting on a heavy credenza. I'm just mentioning that to clarify I wasn't specifically in the chassis soldering stuff or moving wires or anything.

Anyway, I reviewed this lengthy, and fairly entertaining, thread dealing with the same issue: viewtopic.php?f=3&t=510&hilit=blank+lcd

Here is some data:

Measure the following with USB power:
1. Voltage on pin 9 of Atmega.
A. 4.87
1. Voltage on pin 2 of the LCD.
A. 4.90
2. Voltage on pin 3 of the LCD.
A. 2.78
Q. Voltage on pin 11 of Atmega
A. 0V
Q. Voltage on pin 31 of Atmega
A. 0V
Q. Are you sure you held the LEFT key when you were powering up? To be absolutely sure, power it up again holding the key pressed and measure voltage on pin 8 of Atmega while still holding the key pressed. Is it 0V? If it's more than 0.5V-1V, stop there and report.
A. 0V


Disconnect from USB and measure resistance:
1. Between the ground point on the USB connector of the board and pin 11 of Atmega.
A. 0.6ohm
2. Between the ground point on the USB connector of the board and pin 31 of Atmega.
A. 0.6ohm
3. Between the ground point on the USB connector of the board and each of pins 14-21 of Atmega.
A. 11.29kohm, nothing, nothing, nothing, nothing, nothing, nothin, 7.71kohm
4. Between the ground point on the USB connector of the board and each of pins 6-8 of Atmega.
A. 53.1kohm, 53.2kohm, 53.3kohm
5. Between the ground point on the USB connector of the board and pin 1 of the LCD.
A. nothing
6. Between the ground point on the USB connector of the board and pin 2 of the LCD.
A. 6.48kohm
7. Between the ground point on the USB connector of the board and pin 3 of the LCD.
A. 6.72kohm

Also, I can short LCD pin 1 & 3 and clearly see blocks in the top row. So the LCD itself is physically working. Based on my limited education with this project I'm assuming my issue boils down to the Atmega.

I also double checked the buttons were all physically functional (continuity at the button only when button is physically pressed), which they are.

I've been unsuccessful to get Ponyprog to successfully probe the Atmega or read/write to it at all. Probe or any security bit read/writes ALWAYS result in "Device missing or unknown device (-24). I've double-checked my cable with the schematics, tested continuity from the board up to the resistors on the LPT connector, made sure I've connected the cable to the board header properly and to the correct header (clearly labelled on Synthex V2.8 board which is helpful), powered on via USB on the same PC that the LPT is connected, so as best I can tell everything is fine with the cable. And all PonyProg I/O settings match screenshots provided on the website.

I actually have another Atmega32 here via the V2.5 kit I tried to build but it provides the same result. However, I also have no way to know if the other Atmega32 is any good as I bought it new and unprogrammed and never successfully programmed it in the past.

I'm not dismissing some build quality issue on my end. But literally it was working fine, worked through multiple power cycles, I updated the firmware once, and then simply died during firmware update as I originally described.

Suggestions for some specific other things to try?

[dmitri]

I'm not dismissing some build quality issue on my end. But literally it was working fine, worked through multiple power cycles, I updated the firmware once, and then simply died during firmware update as I originally described.

I believe that MD dying during a firmware update is a "red herring". Apparently your Atmega is dead for some reason or there is a short circuit or a break somewhere on the board.