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.
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 https://mutable-instruments.net/archive/ambika/build/firmware/ . 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.
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!
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!