Patch start taking too long, disconnecting

#1

I'm getting this error:
patch start taking too long, disconnecting

So the patch takes really long to compile and then doesnt start. What's the problem?

This is the whole log:
USB device found
connected
Authentic Axoloti Core
exception: soft watchdog
pc=0x802FD84
psr=0x21000200
lr=0x20015FB3
r12=0x802FD41
cfsr=0x400
Firmware version: 1.0.0.1, crc=0xE95BAC96, entrypoint=0x20011000
Generate code complete
Start compiling patch
Compiling patch... with /Applications/Axoloti.app/Contents/Java/firmware
BDIR = /Users/Simon/Documents/axoloti/build
FIRMWARE = .
RM
APP
! /Users/Simon/Documents/axoloti/build/xpatch.h.gch
LINK
BIN
Done compiling patch
Start uploading patch
bin path: /Users/Simon/Documents/axoloti/build/xpatch.bin
block uploaded @ 0x20011000 length 32768
block uploaded @ 0x20019000 length 11876
Done uploading patch
Starting patch...
patch start taking too long, disconnecting
Disconnect request
Done starting patch

P.S. Just found out that I don't get the error when lmnts reverb is not included!

#2

In my experience, this means that an object is broken in a way that leads to a crash or inifinite loop. I've only seen it when testing my own code...

What's the patch look like?

#3

ah thx yes I just found out that lmnts reverb seems to cause the crash.

PS
The patch is massive, way to big to capture in a screenshot.

#4

Weird, I've got that object running... the sound is unstable, but the patch runs.

#5

Yes I've been using it in other patches too but with this particular one it doesn't work.

#6

any Ideas on this one? @Johannes? I would love to use the awesome sounding mi reverb :slight_smile:

#7

(after analyzing the patch)
There is an sdram memory overflow occurring in your patch. The reason it's not getting reported as usual, is that fx/lmnts/reverb uses a newer (pseudo-dynamic) method to allocate sdram that does not (can't) cause a compile-time error, but I had expected such to produce a error message during patch initialization. However that error message does not arrive before Axoloti Core crashes and causes a disconnect. Will investigate further.

Reduce the amount of memory used by tables and delays in sdram and it runs fine. fx/lmnts/reverb uses 32kB of sdram.

#8

ok thanks for investigating here.

I'm using a 16bit table with 4194301 samples for looping. I can only half it's size, meaning I get half the looping time, wich is not an option. So no reverb in this patch I guess. But thanks anyway!

#9

I just learned that the same error happens when you have created more modsources than is set in the patch's View->Settings->Maximum number of modulation sources (and ...modulation targets).
Increased the numbers and all works.

#10

I've just had a similar problem: a delay allocating 2 large buffers using the "traditional" static sdram allocation, plus the reverb that uses sdram_malloc (altogether far below sdram size).

when i flashed the patch to flash it wouldn't start and i was unable to connect (first thought i bricked the axoloti somehow... :astonished:).

now, i replaced the reverb's buffer allocation with

static uint16_t buffer[16384] attribute ((section (".sdram")));

and everything runs fine.

i've also tried using sdram_malloc for my delay buffers (one left, one right) and then got weird artifacts on one of the channel. i suspect there are some issues with sdram_malloc.

#11

thanks a lot for spotting this,I had a lot of trouble with /lmnts/reverb,
after using your fix,it's working now.

the trouble included a lot of other weird stuff,for example when I deleted/added other objects
USING sd-ram to free some space,the patch would't work anymore (huge patch)

it really seems like sdram_malloc is buggy.

I uploaded a mod of /lmnts/reverb to the library under /rbrt/fx

cheers,
Robert