Teensy flash corruption (low voltage issue)?

I am seeing in select cases that the teensy board (w/ audio adapter) is losing its programming. I believe it happens when the voltage goes too low for the regulator to keep regulating. I looked at the datasheet and see some of the LVD registers. Are these enabled by default? I am trying to keep the board in reset when low voltage flag is set to see if it rids of this problem - that is the only lead I have right now.

Any advice is appreciated.

Actually I found the reg reset values. The reset enabled on low voltage detect is set by default, but the voltage level is the lowest setting. Same with warning flag. Could this be causing the issue given I am running overclocked also? I am using a 5V reg into the board, which then goes into the 3.3v reg on the teensy

What Teensy? When do you see corruption ? That should only happen on programming as it stored in flash. Is doesn't take voltage to maintain the program. How do you detect corruption? Are you always on USB or other power with no computer? What does your code look like? Do you have a while(!Serial) stopping the code when no USB serial monitor is activated?

Not enough info to pick one or ask any better questions as what you describe is just odd and won't generally happen - so something is horribly wrong or some info is missing.

The flash memory is very reliable. Many times we've heard reports of Teensy losing its flash memory. It always turns out to be a software problem, where code which works right after uploading fails upon a cold boot. Usually a leftover while (!Serail) or trying to initialize other chips that take time to start up are the most common causes. Sometimes Serial.print() in C++ constructors also plays havoc, because those constructors run before the Serial object has been constructed, so your program crashes before it can even get started.

If you're still convinced Teensy's flash memory isn't retaining your program, please add some code at the beginning of setup() to turn on or blink the LED on pin 13 (or any other LEDs you may have). Or run the File > Examples > 01.Basics > Blink example. You'll see the memory is reliable.

We can help you figure out what's really wrong, if you post your code.

I had a couple units in the field, so I didnt see it first hand. This also happened suddenly while the board was already powered on. I was told in these cases the audio chip played out a loud pop sound and the LEDs on the board did not respond. After powering back up the program would not load, as I have LEDs that should blink on boot. I am using a teensy 3.2 with the audio adapter card. I dont have any while(!serial), but I do use the serial lib to print messages. There is no serial connection in the field even though some messages are still being printed. The board is running off external battery power. I've run the code on usb power for days, and I even tried putting a unit on a power supply and lowering the voltage to see if I could replicate it myself. I have not been able to, so I am grasping at straws right now...

The one corroborating data point is that one user told me his battery was weak enough to deregulate a 5V regulator feeding the teensy. So the guess was the 3.3v reg onboard may be deregulating also?

I understand the flash doesnt need power, but if the processor or some rogue instructions get run it could corrupt something. At least that is my prevailng theory so far...

Nope, the Flash needs special commands and registers if you want to write to it. It is complicated, even if you want to write or erase...
Are you really really sure that it is no software or electronic problem ?

So how can a program run for hours, doing the same processing in the loop() routine, and then suddenly crash and not come up again after rebooting? It's not code.

hyperdyne said:

It's not code.

Click to expand...

It almost certainly is some unexpectedly complex behavior of the code.

Hyperdyne, did you ever figure out what was going on in your case?

I seem to have a similar symptom that this morning seemed to point to flash corruption. I've been chasing it for months, initially pursuing different ethernet adapters and more recently additional filtering on the input of the 7805, all to no avail.

My application is with ethernet, 820io or 850io and teensy 3.2, driving teensy with 7805, and the application is for data acquisition for 11 channels. The application runs for hours or about a day, then seems to crash. In the past a power cycle seems to clear the issue, my process is to remove power and count to 10sec and replace. Today I pulled power and waited 90 seconds just to try something different and the application did not come back up. Because of this last symptom, I am suspecting that the flash has become corrupted. Code is attached.

looking for a clue.

thanks in advance

I never did find the root cause but it still happens. I've spent months trying to figure this out. I originally thought it was a low power brown out corruption, so I added code to issue a warning when that was going to happen. I tested it on the bench with a varying voltage and couldnt replicate the issue on the bench. But I still have occasions where the code will run for some time but then just crash and never come back. So it is some flash corruption as I have to reprogram the board.

twilkers said:

Hyperdyne, did you ever figure out what was going on in your case?

I seem to have a similar symptom that this morning seemed to point to flash corruption. I've been chasing it for months, initially pursuing different ethernet adapters and more recently additional filtering on the input of the 7805, all to no avail.

My application is with ethernet, 820io or 850io and teensy 3.2, driving teensy with 7805, and the application is for data acquisition for 11 channels. The application runs for hours or about a day, then seems to crash. In the past a power cycle seems to clear the issue, my process is to remove power and count to 10sec and replace. Today I pulled power and waited 90 seconds just to try something different and the application did not come back up. Because of this last symptom, I am suspecting that the flash has become corrupted. Code is attached.

looking for a clue.

thanks in advance

Click to expand...

Thanks for the feedback. I'll continue to look as well and let you know if I have any breakthroughs.

Happy hunting.

Tim

Hey hyperdine, in your investigation did you by chance look critically at the reset signal?

I was wondering that, if the flash was programmed but the reset signal was not robust, this possible "poor reset" might produce a symptom similar to a corrupted flash.