I do have a correction of my previous description. In the “crashed” state, the Peaks does respond to triggers initiated via CV, but not via button. None of the buttons work until the power is cycled, but the drums can be triggered and heard at the output. So it appears that just the buttons stop working, and I’ll refer to this as a “lockup” instead of a “crash.”
> I doubt the instruction above can cause a crash.
I know, right? It’s just an assignment. If I just assign the right-hand side to an int32_t, there’s no problem. It even locks up with this code:
lp_state_ += (resonator_output - lp_state_) * lp_coefficient_ >> 15;
/*int32_t output = lp_state_;
CLIP open paren output close paren; // dunno why the forum is messing with this line
If I put the return 0 ABOVE the lp_state_ ± line, then no lockup (but no drum, either, obviously). If I do this:
int32_t iv = (resonator_output - lp_state_) * lp_coefficient_ >> 15;
iv += 0; // just to keep the compiler happy by using iv (warnings are errors)
/*lp_state += iv etc...*/
then also no lockup.
> Are you sure the crash did not occur in an ISR?
I’m ridiculously unsophisticated here. I compile the code with the makefile and transfer the wav file via afplay. So no, no ISR.
Anyway, don’t sweat this, certainly, if I’m the only one with the issue. I’ll mess around with it from time to time, and I’ll add any new information that I discover to this thread. Maybe I’ll pick up a JTAG some day (not for this problem, which I don’t consider a showstopper, but to speed up testing of my own Peaks modulators), and maybe I’ll get some useful debugging messages. Until then, thanks for your time.