Debugging problem

[Sandro]

Hi all,
I recently added to my code a new simple function, apparently harmless; the code is correctly compiled with Arduino IDE using all compiler options. But, if I use "Fastest" option (and I need fastest), even if the code is compiled without errors or alert, on runtime there are multiple errors. I tried for days different actions; I only found that any minimal change (inside the main code or inside most of my classes) makes the problem disappear.
My question is: can this be a compiler's error, either compiler's discovery of well hidden bug? Of course, in the second case I would take advantage of this opportunity and go deeper.

Unfortunately my code is large (https://github.com/SandroGrassia/Lilla-audio-sampler), and as I wrote it's impossible (for me) to isolate the issue (any little change makes the problem disappear)... useless to share the new simple function, it works and doesn't say anything, I belive:

void DISPLAY_frame_color(uint8_t col, uint8_t row, uint8_t chars, uint16_t color)
{
    tft.drawRect((6.0 * col), (12.0 * row), (6 * chars) + 4, 11, color);
}

Does anyone an answer/idea/tip/strategy to suggest?

 

[beermat]

What errors do you have at runtime? I have had a similar experience with "Fastest" in the past, after adding a small amount of new code to a functioning project and executing on the Teensy, it would freeze/lock up for no obvious reasons, and attempts to diagnose with extra code (such as debugging SerialUSB.print messages) would magically resolve the issue; removing the extra debug statements would bring it back. Adding further new code would resolve. Compiling with any other options except "Fastest" would resolve. Although I never specifically figured out the root cause, two things appear to have "solved" this for me, in that I have not had reoccurrences since.

Firstly, this fix (not sure if this is only relevant is you use PSRAM or not):
https://forum.pjrc.com/threads/66525-Teensy-4-1-Freeze-(-1786ms)?p=273624&viewfull=1#post273624

Secondly, using GCC9 to compile:
https://github.com/TeensyUser/doc/wiki/GCC

These are shots in the dark, but may be worth trying.

 

[Sandro]

Hi beermat, the problem you describe looks quite the same problem I'm facing... At runtime there are many malfunctions, but my device doesn't block: display fade-in/fade-out effect becomes inaccurate, short pauses become longer, encoder reading loses many steps, and typical AudioStream "beeep!" indicates that update() call for one (at least) audio objects has exceeded the timing limit. Like in your case, it's useless to change anything in order to make a diagnosis, because everything magically solve the problem. So the first fix, even if valid, couldn't be "verified"; I'll try to use the second tool, the GCC9, than I'll report the results.
Thank you!