Teensy 3.2 behavior function of USB plugged in or not

Hello,

I'm developing a simple custom product with the Teensy 3.2 and I've noticed some bugs that don't occur when the Teensy is plugged into my computer via USB. I am NOT drawing power from USB (I cut the trace on the back of the Teensy).

First, I had several arrays that were global variables (size of 58) functioning as lookup tables. After running for a few seconds, the values of one array were tampered with (bits were somehow set). I decided to make them const such that they were saved in flash, and that problem no longer occurs. But now the Teensy freezes after a little bit of use.

Both of those issues don't happen when the Teensy is plugged into my computer. Does anyone know why?

System setup:
Controls TFT over SPI bus
Reads data from a different device with a clock and data. On CLK rising edge, run interrupt to read data bit. About 58 bits are transferred over 1 millisecond. Repeats every 18 msec or so.

Declaring all variables accessed by interrupt routines as volatile?

I hate blind guesses... The forum rules state clearly that you should post code which allows others to reproduce the problem.

anikhanj said:

First, I had several arrays that were global variables (size of 58) functioning as lookup tables. After running for a few seconds, the values of one array were tampered with (bits were somehow set). I decided to make them const such that they were saved in flash, and that problem no longer occurs. But now the Teensy freezes after a little bit of use.

Both of those issues don't happen when the Teensy is plugged into my computer. Does anyone know why?

Click to expand...

Very likely a bug in your code that overwrites or corrupts memory when things aren't as planned.

Unlikely to a bug in the very widely used Teensyduino core library code, but then anything's possible. As a general rule, I only investigate these sorts of bug reports when they appear to be reproducible. At the very minimum, that involves a complete program to run, and detailed instructions on how to get it to reproduce the problem.

Yes, I apologize. Since this is something I wanted to sell I didn't really want to post the source code. But on top of that, the code takes up about 180 kbytes of memory (quite a bit of stuff going on). The setup also requires a modified Mitsubishi climate control unit and a PCB I made that the Teensy plugs into. For all intents and purposes I think it'd be nearly impossible for someone to reproduce without having the correct hardware anyway.

The Teensy ran an interrupt on the climate control clock rising edge. I decided last night to simply poll the clock/data, instead of running an ISR, for the rising edge then read the data line. This seems to have eliminated my issue. I still have some timing problems but it seems the interrupt was causing the variable corruption. My only guess was the 58khz interrupt was too fast and my routine tried to do too much work before the next interrupt occurred.

If you believe the bug may be in any of Teensy's code, please try to whittle this down to something small and not containing any proprietary code. I do investigate problems, but without code to run I can't do much more than just blindly guess.