Firmware - Stuck at Send SysEx w/ solution.

[gabriel1712]

1. Try doing the update on another USB port, another PC.
2. Try doing the update over a standard MIDI port.
3. Follow my suggestion a few posts up: viewtopic.php?p=10513#p10513

ad. 1 & 2 Been there, no luck.
I guess I'll have to build myself a ICP cable

[Firelord]

Also, bootloader is meant to be protected from being corrupted/overriden provided Atmega fuses are set correctly.

There could be a bug somewhere in the software/firmware relationship.

Do you want me to help finding the cause of the problem or do you want me to jump between posts to get a clear picture?

gabriel1712 tried to update the firmware, selecting different options for the bootloader in MCT. Here's what happened:

* choosing bootloader v2: the initial problem, MD would not accept the firmware update via SysEx being stuck at the "Send SysEx Now" message;
* choosing bootloader v3: now upon powering MD up none of the buttons work, the first line of the LCD reads " pdat# Send S " and the second line doesn't contain any text at all.

10 minutes offline and MD returns to the initial state with working buttons (obviously) and in which it had been stuck at the "Send SysEx Now". Hope I got that right.

My question in connection with this would be: is the bootloader completely independent of the EEPROM memory (i.e. no important data is stored in EEPROM by the bootloader)?

But why the distorted message and why would waiting for 10 minutes matter... yeah, guess it's one of those non-trivial problems again. Hopefully, we will learn something from it.

Also, we need elrules in this thread. Maybe he will be able to better examine this situation from the MCT's creator point of view.

I guess I'll have to build myself a ISP cable

It never hurts to have one around just for a situation like this.

[dmitri]

Also, bootloader is meant to be protected from being corrupted/overriden provided Atmega fuses are set correctly.

There could be a bug somewhere in the software/firmware relationship.

I agree. Here is the source code of the bootloader - viewtopic.php?p=7281#p7281 - very small, no place for guessing. With the fuses set as advised in that post (that is with the bootsection protected from been erased/written), can you tell me how the bootloader can be corrupted, overwriten?

Do you want me to help finding the cause of the problem or do you want me to jump between posts to get a clear picture?

gabriel1712 tried to update the firmware, selecting different options for the bootloader in MCT. Here's what happened:

* choosing bootloader v2: the initial problem, MD would not accept the firmware update via SysEx being stuck at the "Send SysEx Now" message;
* choosing bootloader v3: now upon powering MD up none of the buttons work, the first line of the LCD reads " pdat# Send S " and the second line doesn't contain any text at all.

10 minutes offline and MD returns to the initial state with working buttons (obviously) and in which it had been stuck at the "Send SysEx Now".

My question in connection with this would be: is the bootloader completely independent of the EEPROM memory (i.e. no important data is stored in EEPROM by the bootloader)?

No, the bootloader doesn't know anything about EEPROM, it is pretty dumb.

But why the distorted message and why would waiting for 10 minutes matter...

Even if it had anything to do with EEPROM, how 10min would make a difference compared to 1sec provided there are no electrical problems (loose connections/"high resistance" shorts and etc)?

yeah, guess it's one of those non-trivial problems again. Hopefully, we will learn something from it.

Also, we need elrules in this thread. Maybe he will be able to better examine this situation from the MCT's creator point of view.

Don't see how MCT could have anything to do with it. With the v3/v4 bootloaders, until 'Erased' is seen on the LCD the old firmware should still be there.

I guess I'll have to build myself a ISP cable

It never hurts to have one around just for a situation like this.

[Firelord]

With the fuses set as advised in that post (that is with the bootsection protected from been erased/written), can you tell me how the bootloader can be corrupted, overwriten?

Not yet... I'm just contemplating the possibilities. The source code for the bootloader clears things up a bit, and I must admit that overwriting the bootloader via SysEx would seem rather unlikely.

Even if it had anything to do with EEPROM, how 10min would make a difference compared to 1sec provided there are no electrical problems (loose connections/"high resistance" shorts and etc)?

I'm curious about that myself.

Don't see how MCT could have anything to do with it.

Now that I've seen the source for the bootloader, neither do I. Unless of course the 2.8 kit initially had the bootloader v3 and there was a significant change from v3 → v4. I doubt this though.

[Firelord]

One more thing. If you select the correct ATMega crystal frequency in the bootloader, you can press the left button and MD should send a MIDI message. Was this feature implemented in bootloader v4? If it was there in v3 then it should be possible to check the connection between MD and PC just to make sure that it is all right.

[dmitri]

One more thing. If you select the correct ATMega crystal frequency in the bootloader, you can press the left button and MD should send a MIDI message. Was this feature implemented in bootloader v4? If it was there in v3 then it should be possible to check the connection between MD and PC just to make sure that it is all right.

It was only added to v4.

[Firelord]

ad. 1 & 2 Been there, no luck.
I guess I'll have to build myself a ICP cable

Something else you could try beforehand — check whether ATMega is sitting firmly in its socket, maybe carefully remove it and wipe the pins with alcohol. Let it dry and place the MCU back in its socket. Also try cleaning the soldering points of ATMega's socket if there is any flux left about.

[gabriel1712]

ad. 1 & 2 Been there, no luck.
I guess I'll have to build myself a ICP cable

Something else you could try beforehand — check whether ATMega is sitting firmly in its socket, maybe carefully remove it and wipe the pins with alcohol. Let it dry and place the MCU back in its socket. Also try cleaning the soldering points of ATMega's socket if there is any flux left about.

Thanks Firelord, I'll give that advice a gentle go.

@Dmitri
Should I build the ICSP cable as well, or is it highly unlikely I'll need that too?

[dmitri]

Should I build the ICSP cable as well, or is it highly unlikely I'll need that too?

It's very unlikely you will need it since your MegaDrum is properly detected over USB.

[gabriel1712]

Sooooo... I build the ISP cable following the diagram here: http://www.megadrum.info/content/schematics

1)Installed ponyprog2000
2) I/O port setup > Parallel >Avr ISP I/O > LPT1
3) Device->AVR micro->Atmega32
4) Security & Configuration bits>

Then it pauses for 3 seconds before tossing a sign saying: "Device missing or unknown device (-24)"

MD is connected to USB and Windows sees it.
LPT port is open in the bios (was closed)

Any suggestions?