Can BOD be controlled on Teensy++ 2.0?

[panasyuk]

Hello

Our project had used Teensy++ 2.0 successfully for many years. We started to have problems with EEPROM occasionally failing to store data properly since about a half a year ago. We have not changed anything in the firmware or electronic design.

One of the possible reason for EEPROM failures is brownouts. Is it possible to modify MCU flags controlling BOD in Teensy++ 2.0? What are they set to by default?

Thanks,
Alex.

 

[PaulStoffregen]

The "ext" fuse byte on every Teensy++ 2.0 is set to 0b11110011. The 3 low bit (011) set the brownout detector to 2.6V.

As far as I know, the chip does not support any way for software to change this setting at runtime. Code running on the chip can't disable it, and can't change to different voltage threshold.

There are counterfeit Teensy++ 2.0 boards on the market. If you don't have a genuine board from PJRC, who knows what its settings will be.

 

[panasyuk]

Thanks, Paul! We do buy our Teensys from PJRC. Some Arduino boards allow to specify fuse bytes for the chip in boards.txt file, I suppose they get programmed at the same time as firmware. So, this is impossible with Teensy? Can we do it by connecting ISP programmer to TEENSY?

Do you have any words of wisdom about EEPROM trouble? A couple of years ago we had 100% EEPROM writing success rate, now it is about 75%. We did not make any changes in FW or schematics, but some components went end-of-life and were replaced by similar.

Best regards,
Alex.

 

[PaulStoffregen]

So, this is impossible with Teensy?

Changing the fuse settings isn't supported on Teensy.

Do you have any words of wisdom about EEPROM trouble?

Maybe you could be more specific about what "trouble" means?

You're talking about "EEPROM writing success rate, now it is about 75%", but I don't really know what this means. I have no idea how you're testing or observing this problem.

Maybe you're reading it back immediately after writing? Or maybe you're reading the data back years later and seeing it's different than expected? Or maybe something else? Maybe you're storing a CRC or checksum, which is later doesn't agree with the stored data? Or maybe you have some other way to recognize when the data is bad? So many unknowns.....

Any chance you can separate just the EEPROM writing code into a small program you can share here? Then I can try it on a Teensy++ 2.0 board here, to see if I can reproduce the problem. If it's failing 25% of the time, then I ought to be able to get it to happen (on average) 1 of 4 attempts, right? If only I had the code you're using to test.

 

[panasyuk]

Changing the fuse settings isn't supported on Teensy.

Not even via HVPP?

You're talking about "EEPROM writing success rate, now it is about 75%", but I don't really know what this means. I have no idea how you're testing or observing this problem.

We are calibrating the devices we produce and storing the calibration parameters into the EEPROM. It worked flawlessly for years. Now on about a quarter of devices the calibration is not read back from EEPROM correctly, usually each second byte read is 0xFF instead of the written value. The firmware is absolutely the same, and all it does is calling EEPROM.write in a cycle. It was compiled using Arduino 0021 IDE and is replicated as a hex file.

Maybe you're reading it back immediately after writing? Or maybe you're reading the data back years later and seeing it's different than expected? Or maybe something else? Maybe you're storing a CRC or checksum, which is later doesn't agree with the stored data? Or maybe you have some other way to recognize when the data is bad? So many unknowns.....

Yes, this is certainly the first thing to do. The problem is it would require changing code written by people who left the company a while ago, and the code in question is a mess. Still, it worked for years, I am really wondering why the trouble started only recently.

Any chance you can separate just the EEPROM writing code into a small program you can share here? Then I can try it on a Teensy++ 2.0 board here, to see if I can reproduce the problem. If it's failing 25% of the time, then I ought to be able to get it to happen (on average) 1 of 4 attempts, right? If only I had the code you're using to test.

I really doubt that the firmware is at fault here because it worked for years. It does not do anything trickier than calling EEPROM.write() in a cycle. And we are calibrating each device only once, and EEPROM gets written once, so it is not the issue with exhausting EEPROM writes.

The only idea which comes to my mind is that power supply on our calibration fixture goes south and can not maintain proper voltage during EEPROM writes, that's why I am pestering you about BOD .

Best regards,
Alex.[/QUOTE]