Ambika build has noisey SPI bus [SOLVED]

I put together an ambika, and i noticed that the SPI bus is just blasting out constant seemingly nonsense data and SS’s. I traced some of the code and it looks like it should be sending out voice sync in the main loop.

When i probe the inputs into the 74hc138, it appears the main micro is actually telling it to select all different slaves (including SDcard) in a repeating and weird pattern. Its really hard to parse if the clock and miso/mosi lines are sending good data or just noise.

Anyone have any idea what the source would be? All the menus except the sdcard menu work solidly (the library one works sometimes and freaks out other times). When i have voicecards plugged in, they make a repeating patterned tone, and when i turn the encoder in the library it makes a beep on all voices.

Did you compile the firmware yourself? Or did you use one of the precompiled hex files?

The firmware is so filled up, that using the wrong compiler version results in code being too large or too slow (different optimization). This can break all sorts of things.

I did compile it myself. That is surprising I was unaware that it could actually break the synth.

I used avr-gcc 4.8.1 which is what brew installs if you install the: osx-cross/avr/avr-gcc@4

There was a slight problem with the avrlib/op.h using some under constrained andi registers, and i had to move the bootloader up a few places because it was bigger. But it seems crazy that 4.8.1 would create broken code compared to 4.3.3

Follow up question, anyone know any way to actually install 4.3.3 on mac os? (i cant wait until work replaces this pile of garbage)


there’s some information on maximum code size (Edit: actually built binary size) and recommendations for compiler version at . It is a known issue that later versions of the compiler tend to produce too large code to fit the chips, but I honestly cannot tell if this is related to the issues you experience.


I was aware of there sometimes being a problem with size of code, but it actually fits. So if it’s a avrgcc version problem, it’s because it somehow introduced a bug.

I’m going to use the hexs tonight to test the theory. It would be nice if it was easy to manage multiple specific versions of avr-gcc.

Just a note: I believe it may be perfectly normal that the mobo is constantly talking to (selecting) each voicecard to update lfos etc so this in itself is probably not the issue.


Im going to double check tonight to confirm it’s also bringing the SD reader SS high constantly too, because that’s not expected as far as I understand.

Can confirm, its still making weird noises even with the precompiled hex’s

Okay. Then it’s probably a soldering defect somewhere on the motherboard

i wish i could figure out for sure where, because ive not found any yet lol.

reflowed all the areas that as far as i can tell could possibly be involved in this (considering everything else appears to work (display, menu diving, buttons etc) No luck.

Last night i got sysprogs analzyer2go working with my cypress fx3 dev board (it works amazingly btw). It looks like the voicecards are replying with FF, a whole lot, and the master is shooting out complete madness to the voicecards. Lots of data that isnt even listed in the tech notes as actual SPI commands used by the ambika, with a few real commands like 00x50/51/52 laced throughout.

im going to replace the atmega644p and recompile and re-flash everything tonight.

Fixed it last night! it wasnt the hardware at all. I had massaged some minor things in the firmware code to get it to compile and fit with newer version of GCC-4. Last night i hunted down the OG 4.3.3 version it was originally written for.

I powered it up, tested tweaking knobs, everything appaears to be working now! huzzah!

You managed to get it compile fine using a brew version of avr 4.3.3 ? I’d like to compile the ambika firmware on my Mac using a brew solution or virtual machine/environment…

you can get specific versions here. indispensable

1 Like

that looks awesome, never found it while searching the interwebs. Will definitely check it out later today :slight_smile:

So I managed to compile it downloading a 2010 version. I did have to change the source code to

// #include "voicecard\resources.h"
#include "resources.h"

on both voice card and controller.

Just out of interest, what was the buggy ‘minor change’ you made that broke the firmware for newer GCC?

I’m currently trying to compile MIDIPal firmware using GCC 8.2, but it also required ‘massaging’. But I’ve been spending ages trying to diagnose some lingering bugs. It’s definitely not a size thing, I’ve checked both the static/flash size and the RAM usage during runtime, so at this point I’m out of ideas.

I would suggest getting the old crosspack. The changes i had made were to due to some of the assembly code having registers appearing to be assigned wrong, I had thought i had it working but so many weird issues with timing were happening (probably because thats what a lot of the assembly code does in the ambika source).

Yeah, getting crosspack is my current plan of attack. Then if I have the time and inclination I might compare the output .elf files. Unfortunately I am on linux so I’ll also have to find a way to run it…
Thanks for the advice!