Debugging axo's

#1

Hi guys,

I'm working in an object and and it's crashing after I added a pretty innocent line of code. 

	void setDecayTime(float f)
{
	static const float minTime = 1.0f;
	static const float maxTime = 2.0f;
	static const float range = maxTime-minTime;
	decayTime = (f*range + minTime) * samplerate;
}

If i remove that last line, everything is fine, but otherwise, it compiles but when it runs it does nothing (no sound, dsp load is 0%)
How do you debug such a problem? Running it in a debugger would be great of course, but maybe its possible to print to the console somehow?
The code runs fine on osx.

thanks.

#2

hard to say why its crashing without seeing context....

you can insert logging, which gets sent to the Axoloti console:

LogTextMessage(const char* format, ...)

just use it in the same was as printf, just be careful not to send too much logging. (board will disconnect if you do)

#3

Thanks! I should be able to track down the problem with that.

#4

After trying lots of different things, I concluded there really isn't anything wrong with my code and tried setting the optimization level to -O2 in the Makefile.patch. That solved everything, although at a slight increase of cpu usage. I will try to turn on individual optimization flags to see what happens. Any one else run into this?

#5
  • I haven't seen problems with -O3.
  • LogTextMessage uses chprintf rather than standard libc printf, and I think it is compiled without float support (CHPRINTF_USE_FLOAT).
  • I don't have enough context to understand what you're trying to do with the function at the top of this thread.
  • An empty patch shows 2% dsp load, if it shows 0% it may not have been loaded somehow?
#6

Hi Johannes,

I'm porting a guitar multi FX o wrote of osx to axoloti. The code is bit too much to post here. The method above just sets some feedback level for the reverb and is called at krate.
The thing is, occasionally I get the 0% cpu after i have made some very minor change in code, which could not possibly cause any problems by itself.
I added some logging at initialization which is working normally, but when I get the "0%" none of the logging is printed to the console either, so maybe the patch isn't started somehow. But there are no compile errors and the console says:

Done compiling patch
Start uploading patch
bin path: /Volumes/Intern/Users/fokke/Documents/axoloti/build/xpatch.bin
block uploaded @ 0x20011000 length 12980
Done uploading patch
Start starting patch
Done starting patch
Start locking
Done locking

which makes me think everything is fine. Maybe the patch the patch is too big ? (perhaps unlikely at 12980 bytes). Could it be some kind of exception is happening?
Is there a way to turn on some more verbose logging?

I mentioned in that setting set using -O2 rather than -O2 seems to solve the problem. But know i've changed that to
-O2 -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-loop-vectorize -ftree-loop-distribute-patterns -ftree-slp-vectorize -fvect-cost-model -ftree-partial-pre -fipa-cp-clone

(which according to the gcc manual should do the same thing as -O3) And the patch runs fine (although is now only 9612 bytes) .....so i am a bit confused here.

Of course editing the Makefile is not really a permanent solution, and I don't think it actually fixes the real problem.

#7

For full debugging you need to connect an stlink


Or maybe inspecting the contents with objdump of the compiled patch can reveal the source of the issue?
Maybe a stack overflow causing corruption?

Exceptions generally cause the microcontroller to log the source of the exception
and reboot and this is reported after booting.

#8

Hi Johannes, thanks for your input.
The problem seems to have resolved itself again for some reason :smile: But the low level debugging is good to know.

#9

Ive have seen major issues with optimisation ... it gets quite common when you start building more complex objects.

for me the issue was (and there are quite a lot of variations) is -O3 is very aggressive at inline coding, this is partly down to the way axoloti creates everything into one file (xpatch.cpp) and so it appears to the compiler as being a likely candidate for inlining. this inlining obviously increases the memory footprint of the code significantly - when you use -O2 it reduces the likelihood of inlining.
however if you look at the GCC manual you will find there are preprocessor directives you can give to functions to explicitly tell the compiler to not inline.

(cpu performance obviously drops when you don't inline as its an extra function call, hence the art of performance tuning, deciding where you want to take the hit)

probably in the mid-term axoloti should allow for multiple source file includes, and also for compiler options to be specified.

#10

I stumbled upon a new open source embedded systems emulator called Emul8, and I'm wondering if that could be useful in some cases. The STM32F4 core is supposed to be supported at least, but I'm not sure about all the on-chip peripherals that Axoloti requires.

http://emul8.org/get-started
https://github.com/emul8/emul8

#11

I believe especially usb host+device and sdcard 'd be a lot of work to add in an emulator...
An emulator is possibly useful to step through some object code if there is only very little interaction between a test-patch and firmware. To debug objects I most often use patches in real time to diagnose object code, sometimes with some extra outlets added for diagnostics.