EEPROM not ready on new Teensy 3.2

J

jrdarrah

Well-known member
I started using a new teensy 3.2 for some code that references EEPROM data. The code works on another older 3.2. In trying to debug the code I extracted the part of the larger program to only include the problem area.
The code isn't complicated. Get the size of the EEPROM and byte by byte set it to 0. When I run the program it never gets past the 1st location because the function EEPROM.isReady() never returns true. Do I have a bad Teensy or am I missing something?

Serial Started
2048
0
0


Code: 
#include <EEPROMex.h>
#include <EEPROMVar.h>


void setup() {
  unsigned long delayStart = millis();
  Serial.begin(115200);
  while (!Serial && (millis() - delayStart) <= 1000);
  Serial.println("Serial Started");  
  // put your setup code here, to run once:
 Serial.println(EEPROMSizeTeensy32);
  // erase the whole eeprom
  for (int i = 0; i < EEPROMSizeTeensy32; i++)
  {
     Serial.println(i);
     Serial.println(EEPROM.isReady());
    while (!EEPROM.isReady());  //wait until eeprom is ready
     EEPROM.updateInt(i, (byte) 0);
  }
}

void loop() {
  // put your main code here, to run repeatedly:

}
 
I did some experimenting and found that the two Teeny 3.2 boards that I bought from PJRC.COM recently show the error where the eeprom never returns ready. I found an older board that I've had for at least a year, worked as expected. The arduinio IDE is1.8.13 and Teensyduino is 1.56. I'm thinking that changes to the new board (maybe firmware) was made that was incompatible with the EEPROMex. Any ideas on how to get the new board to work would be greatly appreciated.
 
The indicated EEPROM headers are not to PJRC Teensy provided libraries.

Try using a TeensyDuino included example that uses the PJRC EEPROM.h library code.

I just tested this example on a T_4.1 to work: EEPROM\examples\eeprom_read
 
And the code @defragster used on a T4.1 also works on a T3.2

Part of the problem may be that you are running the most recent version of Teensyduino on a rather old version of the Arduino IDE. The current version of the Arduino IDE is 1.8.19.

Pete
 
Thanks Pete - Didn't try on a T_3.2 here as I've not gotten any new ones recently.

These includes are likely using some incompatible code:
Code: 
#include <EEPROMex.h>
#include <EEPROMVar.h>
 
the read example didn't use isReady or eeprom_is_ready which is what the EEPROMex calls. I looked at the code and the isReady goes back to in eeprom.c found in C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\eeprom.c. The problem seems to be that it responds differently (and correctly) on the older teensy 3.2 but not on the I bought in Sept 2021.

Code: 
int eeprom_is_ready(void)
{
	return (FTFL_FCNFG & FTFL_FCNFG_EEERDY) ? 1 : 0;
}
 
Sorry to be adding more information along the way but I wanted to see what was different between the older board that worked and the two newer ones that didn't.

The processor chip that worked was labeled

MK20DX256
VLH7
3N36B
CTER1644B

The two that failed were the same except for the last line

XNGR2009N
and
CTBR1827A

more data points. I'm hoping if I get enough a pattern will emerge to get to a solution with my eeprom problem.
 
this may be a duplicate. Not sure where my last reply went. El Supremo I order all of my Teensy boards from PJRC. I want to support them and also know I'm getting genuine boards and not a cheap knock off. I upgraded to the latest versions of the arduino IDE and teensyduino. The new boards still fail.
 
the EEPROMex is an extension to the EEPROM code to make saving data types easier. I've used it for years without problem. The EEPROM code it uses seems to be this one - C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\eeprom.c at least based on tracking the code related to isReady.
 
Not aware of any T_3.2 change that would account for a chance in function, but using an external library may require change or update.

As indicated in post#3 - using the PJRC supplied EEPROM.h is the real test for any problem. If that code works the problem is in the additional interface code.

Note: the .get and .put and other Arduino EEPROM interfaces fully support saving any data types and are implemented in PJRC's EEPROM.h.

And EEPROM.isReady() makes no sense? If the Teensy is running then the EEPROM should be expected to be ready and working as it is included hardware in the Teensy. If it isn't Ready then setup() would not have been called.

Try starting with the included examples as done in post#3 - modify them to test read and write and restart ability to confirm function. If code can be shown to not work with EEPROM.h alone please post for investigation.
 
jrdarrah said:
Sorry to be adding more information along the way but I wanted to see what was different between the older board that worked and the two newer ones that didn't.

The processor chip that worked was labeled

MK20DX256
VLH7
3N36B
CTER1644B

The two that failed were the same except for the last line

XNGR2009N
and
CTBR1827A

more data points. I'm hoping if I get enough a pattern will emerge to get to a solution with my eeprom problem.
Click to expand...

The last line of MCU etching contains a batch production date. CTER1644B is year 2016 and week 44. ) I don't have any "recent" T3.2's. I have one with CTAD1806B. I fetched the EEPROMex library, and your sketch (post #1) didn't compile :( I had to define EEPROMSizeTeensy32, 2048). The sketch then worked on all 5 of the T3.2's that I have, including the 2018 T3.2.

output ended with:
Code: 
...
2046
1
2047
1

Unable to reproduce your problem using 1.8.15 with 1.56 and "older" T3.2s
 
Last edited:
jrdarrah said:
the EEPROMex is an extension to the EEPROM code to make saving data types easier. I've used it for years without problem. The EEPROM code it uses seems to be this one - C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\eeprom.c at least based on tracking the code related to isReady.
Click to expand...

I downloaded the EEPROMEx library from github and tried to build your sketch. The constant EEPROMSizeTeensy32 is not defined, so can you tell us what is that value, and did you make any other changes to the code from github?

If I make one change to your code, to modify EEPROMSizeTeensy32 to EEPROMSizeTeensy31, your sketch runs fine on my T32. One thing I see, though, is you are using UpdateInt(), which writes an INT16 to write to each BYTE address in the EEPROM. That's not correct, and it could be part of the problem. Here is your sketch modified to use the TeensyDuino built-in functions. Try this on your boards. If it works, then you know the problem has something to do with EEPROMEx. Just FYI, the built in EEPROM.h includes templates get() and put() that will let you read/write any variable of any size, as long as you make sure that the starting address in EEPROM is such that you don't try to write past the end of EEPROM.

Code: 
//#include <EEPROMex.h>
//#include <EEPROMVar.h>

#include "EEPROM.h"

void setup() {
  unsigned long delayStart = millis();
  Serial.begin(115200);  
  while (!Serial && (millis() - delayStart) <= 1000);
  Serial.println("Serial Started");  
  // put your setup code here, to run once:
  Serial.println( EEPROM.length()/*EEPROMSizeTeensy32*/ );
  // erase the whole eeprom
  for (int i = 0; i < EEPROM.length()/*EEPROMSizeTeensy32*/; i++)
  {
     Serial.println(i);
     Serial.println(eeprom_is_ready()/*EEPROM.isReady()*/);
     while (!eeprom_is_ready()/*EEPROM.isReady()*/);  //wait until eeprom is ready
     EEPROM.write( i, (byte)0 )/*updateInt(i, (byte) 0)*/;
  }
}
 
jrdarrah said:
the read example didn't use isReady or eeprom_is_ready which is what the EEPROMex calls. I looked at the code and the isReady goes back to in eeprom.c found in C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\eeprom.c. The problem seems to be that it responds differently (and correctly) on the older teensy 3.2 but not on the I bought in Sept 2021.

Code: 
int eeprom_is_ready(void)
{
	return (FTFL_FCNFG & FTFL_FCNFG_EEERDY) ? 1 : 0;
}
Click to expand...

looking at eeprom.c, it looks like for read's and write's it tests if eeprom is ready, and if it is NOT, it calls eeprom_initialize(). So maybe one needs to run one of the examples from teensy eeprom lib to initialize the T3.2 eeprom, and then try your test sketch .... Or in other words, your test sketch won't work if T3.2 has never initialized its EEPROM.
 
Last edited:
manitou said:
looking at eeprom.c, it looks like for read's and write's it tests if eeprom is ready, and if it is NOT, it calls eeprom_initialize(). So maybe one needs to run one of the examples from teensy eeprom lib to initialize the T3.2 eeprom, and then try your test sketch .... Or in other words, your test sketch won't work if T3.2 has never initialized its EEPROM.
Click to expand...

That makes sense for NEW units if the code in use doesn't do or that trigger that CORES provided initialization.
 
OK, i had a T.32 (batch 1805) that had never had its EEPROM used, and the sketch in post #1 hung! After running one of the T3.2 EEPROM examples, then the post #1 sketch ran. ;)
 
snevermind, I added eeprom_initialize(); to my program and now it works on both newer processors. Would the initialize set the eeprom to all zeros? If so I'll just use the initialize instead of my code to clear things out. That gets me going but how does this situation need to be handled longer term?
 
Using PJRC provided libraries would have worked. It only needs to be done one time to allocate and configure the EEPROM storage area on a Teensy when new.

If using external libraries, they need to be confirmed to be complete and compatible. In this case that library seems to need an update to allow for calling eeprom_initialize() to work on new units.
 
jrdarrah said:
snevermind, I added eeprom_initialize(); to my program and now it works on both newer processors. Would the initialize set the eeprom to all zeros? If so I'll just use the initialize instead of my code to clear things out. That gets me going but how does this situation need to be handled longer term?
Click to expand...

i don't think the eeprom_initalize() sets or changes any values in the EEPROM.

You might just remove all references to EEPROM.isReady() in your sketch and let the EEPROM read's and write's fall through to the Teensy core which should call eeprom_initialize() if required. But I don't have any more virgin T3.2s to test that solution.
 
Last edited:
You must log in or register to reply here.
Back
Top