Ambika crashes if cyclic voice allocation is selected

The subject line says it all. After a great deal of firmware troubles (I had ended up using two different computers and two different ISP’s) Ambika seems to work quite nicely with all 6 SVF voicecards, but if I try to select cyclic voice allocation from menus, ambika stops responding (straight up frozen, no buttons work, all light stay as they were, midi trigs no notes).

Voicecard MCU’s are programmed by yours truly, the motherboard MCU is from mutable.

While I’m at it - I’m no newbie when it comes to electronics and computers, but I am little miffed over the fact that I was having so much trouble burning the firmware. First of all, the avrdude commands proivided want to set efuse to 0xFD. This will not happen, no matter what I do - verifying the fuse always returns it as 0x05, which is the same bitmask pattern concerning the lowest three bits - the only bits that actually matter. Is this normal? The 328p-pu ignores the highest 5 bits and always returns them as zero?

Second trouble was burning the firmware files themselves, especially the flash, second part. First one, ambika_voicecard.hex, goes into the chip and verifies correctly, Second one always returns verification error at the first byte (ambika_voicecard_boot.hex). EEPROM part goes in without complaints, when I use avrisp mk 2 - using tinyusbisp was much more flaky, I got verification errors all over the place, no matter what -B parameter or baud rate I tried (and yes, I tried multiple versions of avrdude, tried burning with powered hub and without it, messed with configuration files and suggested delay parameters).

I had really fun time using tinyusbisp - sometimes after the fw burn cycle the card would light the note led (when still connected to programmer), sometimes not. When inserted into ambika I saw either the card randomly work, sometimes it light up the data led as expected but the card offlined itself after few seconds, sometimes no operation at all, most of the times the note led would light at boot-up but otherwise no operation (and of course the “install” function would not work).

Every card I built FINALLY in one way or other came online in ambika (and yes, I was sure not to tease the cards with quick power-on-power-off sequences). One card decided to create weird digital artifacts in sound when note was playing like a sounds from granular synthesis, if you’ve ever heard one - most of the sound was ok, but here and there some glitches which were not cyclic - changing the atmega to a new one fixed that.

So. Any tips regarding the firmware? Has anyone ever burned the voicecard MCU’s with verification on, and gotten away with it without errors? Should I rip the cards out and burn them all once more, since I suspect that the freezes-when-cyclic-selected may stem from the voice card firmwares being in an inconsistent state?

Did you try flashing the voicecards on the Ambika itself thru the SD card?

> since I suspect that the freezes-when-cyclic-selected may stem from the voice card firmwares being in an inconsistent state

No. Communications with the voicecards is one way. So whether you have healthy voicecards or nothing at all should not matter to the MCU. Try removing voicecards and see for yourself…

It freezes as soon as the menu hits “cyclic” or later when a note is sent?

shiftr: flashed with programmer providing power to individual cards (ie. the voicecard sitting on table all alone). Once I had any activity on the card inside Ambika, I used upgrade function to flash the cards from SD, just to be sure. Usually after this the cards became stable.

Pichenettes: Freezes as soon as the word “cyclic” appears on the lcd (using a pot to select the parameter). Nothing was playing.

One question, though. SD contains only one file for flashing, and the firmware procedure has three files (two flash files and one eeprom). Is this correct? The ambika only changes one of the files inside the voicecard, and the initial programming covers all three?

Ah, never mind that. I just realized that .bin files are binary format files which have all the .hex files in raw format, and .hex files have all this extraneous data in them.

There is a flash file for the bootloader, for the main firmware code, and an eeprom file for the initial factory settings. So when you do a firmware upgrade by SD, only the firmware code has to change. The bootloader is permanent, the factory settings have to be put there only once.

Ah, so that is the way it is. I take it that only the bootloader has to be intact on the voice card for the install function to work once the voicecard is inside Ambika itself? And once the card has successfully booted just from the bootloader, no leds light up, but then the install function loads the actual firmware to the card? And when both files are in, the data led lights up (since now the card is actually running a program which can receive commands from motherboard)?

Yes, you’re correct about all points.

The hex files loaded into the chip when you run the flashing script already contain the main firmware, so normally you don’t have to do the SD card load after having flashed the files through the ISP header.

Note that if a voicecard is not assigned to any part, the orange LED (data) will not light up.

I had my Ambika freeze once when I turned to cyclic while notes were playing. With no held notes it’s OK.

mine did also freeze

Will have a look. In which mode was it set before you selected “cyclic”? How many voices allocated to the current part? Were there notes still playing?

I personally was rotating through the modes, so from poly onwards, whatever mode there is just before cyclic. Side note: it is possible that midi clock was coming in, although no notes were playing.

my ambika freezes if you play some notes while changing to a patch that uses cyclic voice allocation.

Yeah, same problem - internally it’s like changing the setting…

It’s happening every time when I turn from 2xuni to cyclic when notes are being held. Sound stops and Ambika stops to react to anything. Can you see that too?

This had been fixed… here
Only can’t seem to locate the right file at the moment. I believe there was another fix after this?

Any news on this? I’m having same issue.

Well yes I’ve post a firmware update file here. Have you applied this update?

Cool! Thanks. First time I got on that page I could see the zip-file available, second time I didn’t. Now it’s showing up again. :slight_smile: