Teensy3.0 EEPROM erased after reset too...

Status
Not open for further replies.

bretskee

Member
Hi,

I am using a Teensy3.0 and wanting to save some configurations to EEPROM. I am using teensyduino1.14 and arduino-1.0.3. I have read about EEPROM erasure after sketch upload but I see it also after reset.

The delay(10000) is simply time for me to start the serial monitor but the result is the same for upload and reset.

the Output is always:

ÿ
A

the second time it is run and after a reset rather than a upload, i would have expected:

A
A

Any help would great... thanks.

Code:
#include <Arduino.h>
#include <EEPROM.h>

void setup()
{
  Serial.begin(9600);

}

void loop()
{
  char character;
  
  delay(10000);
  character=EEPROM.read(0);
  Serial.println(character);

  EEPROM.write(0,'A');
  
  character=EEPROM.read(0);
  Serial.println(character);

  while(1);
}
 
There must be someone out there using EEPROM. My code above works as expected on an arduino. What am I doing that is so dumb??
 
Teensy3 has a known issue where uploading erases the eeprom. Only resetting the chip does not erase the eeprom.

A full chip erase is done at the beginning of every upload. A future version will change to a partial erase which preserves the eeprom (like Arduino and Teensy2), but for now every upload wipes the eeprom.

Simply resetting the chip should preserve the eeprom, so you can use it for storing data. But that data is erased every time you upload a new program.
 
My post explains that I am seeing erase after reset too. If you upload my code then the first output is seen. If you then reset causing the code to run again, the stored data is not persistent.
 
Hi,

I tested the example and it works as expected.
After cycling the power (I unplug the USB connector and plug it in again), the previously stored value is shown.
How do you reset the board?
 
I just use the reset button. I have not been power cycling the board. I will try that. Can you tell me what your environment is? Arduino and Teensyduino versions?
 
I am using Arduino 1.0.4 with Teensyduino 1.15rc1 and do the reset by power cycling.

But when I press the button on the Teensy during work with the Arduino IDE, it shows the behaviour you describe.
As by pressing the button on the board the Teensy bootloader is activated, maybe just entering the bootloader is already erasing the EEPROM?
 
I just tried reset via power cycle instead of reset switch and EEPROM contents is preserved. So, it seems reset exhibits the same 'bug' as program upload. Great catch Josef, thanks.

So Paul, do you have comment on what might be going on here or how long it might be until we see a fix??
 
My experience of using the Teensy environment on Windows is that if the teensy loader is active (and in auto mode) on the computer it is plugged into when you hit the reset button, it'll automatically upload the last compiled program to the teensy that just got reset (even if you hadn't actually just recompiled the code). Closing the arduino ide does not automatically close the teensy loader, so it's quite likely that each time you hit the reset button you triggered the Teensy loader into automatically reprogramming your teensy.

Using the reset button restarts the teensy in "programming" mode - your code does not run at that point. The teensy then waits until it's rebooted again - it does not actually start running your code until after that reboot. It would only run your code after a second reboot...such as the one done automatically when reprogramming is finished.

I believe that the only way the reset button could have resulted in your code being run is if an automatic code-reprogram was triggered - the Teensy would wait forever in programming mode until the next time it was power-cycled otherwise.
 
Yep, that is what is happening. Good explanation!
It is the combination of entering the bootloader by pressing the button on the Teensy and the following automated reprogramming and rebooting via Teensy Loader.
 
Thanks for your help guys. When my code and hardware is complete, I will not be connected and battery powered and none of this will be an issue I guess. It is interesting to understand this behavior during development though.
 
Yep, that is what is happening. Good explanation!
It is the combination of entering the bootloader by pressing the button on the Teensy and the following automated reprogramming and rebooting via Teensy Loader.

Yes, exactly.

Any uploading starts with a full chip erase, then everything you write (whatever the Teensy Loader sends) is written to the freshly-erased flash. Currently, the chip's flash controller's "Erase All Blocks" (command 0x44) is being used to erase the chip. I do have the ability to change which erase command(s) are used, but it's very tricky business. Using 0x44 is the safest option. Teensy Loader doesn't cause any of the chip's many anti-write protection features to be set, but if they ever did get set, combinations of other erase commands might not unset them. That's why I went with 0x44, to minimize the chance your Teesny3 could be bricked.

So Paul, do you have comment on what might be going on here or how long it might be until we see a fix??

Very likely before Christmas, but unlikely within the next few weeks.

For stuff like serial drivers, normal Arduino libraries and other user-level code, I'm pretty willing to publish experimental software. But how the chip gets erased needs to be considered very carefully and needs to be tested throughly. If it's done wrong, you could end up with a board that can't be reprogrammed.

Right now, my top priority is the Mac OS-X issue, so I'm not even working on this part at the moment. But the Mac stuff is turning out to be pretty involved and I'm having to dig pretty deep into how the Teensy3 and Loader interact, so I'm at least thinking about how this erase stuff and the low power changes will work.

I know it's pretty inconvenient losing the eeprom when you upload new code, but at least you can know it will be preserved when you're done developing code and ready to actually use the project.
 
Status
Not open for further replies.
Back
Top