Digital FX - FX good, filter not working

So I’ve got my digital FX board just about working now and the effects sound cool as hell. The only problem is that only >fx mode works correctly - when I try to use the filter with them, something goes awry. It sounds crackly and fuzzy and overall not good. It has weird, sort of colorful popping artifacts, almost like a corrupted MP3.

I tried compiled the firmware and then burned it w/ fuse bites using avrdude on another machine, so I was only using the makefiles for compiling, not for burning. I got an error saying that the efuse bit got set back to 0x05 after I set it to 0xfd, but I guess this is equivalent since only the 3 least significant bits are used, and when I burned 0x05 to it, it worked fine. So maybe this is related?

I will see if I can burn from the machine I compiled on, maybe that will help.

I had some issues with my control board though but I don’t even want to think about that tonight. I just wanna play with these sweet effects, and hopefully get some filter joy before I pass out for the day.

I just did the regular “make -f dsp/makefile bake” from the machine I compiled on. It gave the same error for efuse but this time it charged on ahead. The outcome seems to be the same, with only the non-filter mode working. Also it looks like only the non-interpolated delay algorithms are working correctly.

It really seems like it’s not running fast enough to handle the load of the effects. If the fuses were set properly, though, it should be running from the external crystal and thus at the correct speed, right? What else could cause this?

I think I read that the chip by default uses an internal clock and that setting the fuses tells it to use the external one?

That was my understanding too. But why isn’t that efuse getting set? Is that the normal behavior?

I tried baking another Atmega328p. When I did it in the digital fx board, it said the chip had identity 0x000000 and it couldn’t bake it. Then I put it in an Arduino and baked it using its ISP pins. That gave me the same result that the first MCU gave, where everything looked OK except efuse wouldn’t set properly. I put it in the digital board and it’s the same deal where it seems to be running too slow.

The only thing I could think of that might have gone wrong otherwise is that I failed to order the correct 8 100n caps so I dropped some replacement ones in there.

I’ll try resoldering and see if I have any luck.

No luck with resoldering.

From what I’ve read the lfuse seems to be the one responsible for describing which clock is used. I verified that this has the correct value of 0xFF even though it doesn’t seem to be using the crystal oscillator correctly.

Do you still have to compile this with an old version of avr-gcc? I tried using 4.5.3 on my Ubuntu machine for the control board firmware, and the moose said it was too big. If it’s too big for that, maybe it’s too big for the DSP firmware too? I didn’t get any out of range errors, though, so that’s probably not the problem. Though it would be nice if I could compile the control board firmware as well.

what is the size of the firmware file you have built?

Control board = 65712
Digital FX = 30282

The firmware size for the digital FX board MCU is good ; but the file for the control board is too large. Are you trying to build the latest version? It’s 62580 bytes here so even with the 1.5k-2k overhead introduced by the last gcc you should still be good…

Maybe you can upload one of the prebuilt .hex for the control board?

Oh, yeah, when I use a prebuilt .hex, the control board works fine. I was just doing that to test whether there was something wrong with the compilation environment - it seems like there is.

I would prefer to compile myself, if possible. But if there was a prebuilt .hex for the DSP board I would just use that at this point, at least so I have a backup if I never do get compilation working.

Is it still possible that this isn’t a software problem? It seems to me like it must be software since I can get audio OK when I use certain effects algorithms without the filter. But maybe there’s some possible hardware issue I’m not thinking of.

There is one

Whoa, you’re fast… How did I miss that .hex?? I will try and report back. Thanks

Works great now! OK now to figure out what the heck was wrong with my build environment…