UC3 Fuse write cycles limit and AS6 Programming settings?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am confused with the UC3 fuses (lock) maximum write cycles.

On both UC3 A0 & A3 datasheets it writes that the flash has a maximum 100K write/erase cycles but for the General Purpose Fuses its 1000 only. Why they have different endurance as it looks like its the same flash? Also i didn't find any clear info of the security bit endurance as with the other memories.

The default programming option of a AS6 project is with a chip erase. I assume that this has the same meaning with the chip erase of the programming window and that means it erases all the flash the general propose fuses and the security bit except the 512bytes user page flash for UC3.

So does this means after 1000 debugging sessions with the chip erase by default option will probably no be possible to use the general propose fuses and the security bit or even worse not to be able to reprogram the chip at all?

Please correct me if i misunderstand something from the datasheets and the user manuals of the UC3 AVRs.

Last Edited: Fri. Jul 20, 2012 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know nothing about the UC3 but for AVRs the 100K write/erase cycles is for the EEPROM and 10,000 for flash.

Fuses are NOT normally erased as part of a chip erase and you only need to change the fuse only a few times in the life of the chip, maybe once only.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This from AT32UC3A summary datasheet

- 100 000 Write Cycles, 15-year Data Retention Capability
- 4 ms Page Programming Time, 8 ms Chip Erase Time
- Sector Lock Capabilities, Bootloader Protection, Security Bit
- 32 Fuses, Erased During Chip Erase
- User Page For Data To Be Preserved During Chip Erase

and this is from the AT32UC3A0 complete datasheet (Fuses Settings) pages 36 & 37

The flash block contains a number of general purpose fuses. Some of these fuses have defined
meanings outside the flash controller and are described in this section.
The general purpose fuses are erase by a JTAG chip erase.

Flash General Purpose Fuse Register (FGPFRLO)
LOCK[15:8]
LOCK[7:0]
The devices are shipped with the FGPFRLO register value: 0xFC07FFFF:
After the JTAG chip erase command, the FGPFRLO register value is 0xFFFFFFFF.

from 18. Flash Controller (FLASHC) chapter page 115

Dedicated command for chip-erase, first erasing all on-chip volatile memories before erasing
flash and clearing security bit.

What does actually write cycle means? the transition from 0 to 1? what happens when we make chip erase and some pages from the flash are already ones, does it count as a flash write cycle on that pages?

It's confusing why the FGPFRLO register has only 1000 write cycles when the flash memory has 100k cycles.

Why there isn't any similar lock bits write cycles limitation also with the 8bit AVR's on their lock bit flash registers but its 10k flash writes as i assume?

I don't know how flash memory is implemented and works on MCUs so please help me if you know to understand it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why there isn't any similar lock bits write cycles limitation also with the 8bit AVR's on their lock bit flash registers but its 10k flash writes as i assume?

Even if it were 1000 for an AVR8 why would it matter? Changing fuses and lockbits is probably something you only ever do about 2 or 3 times across the entire life of a chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Why there isn't any similar lock bits write cycles limitation also with the 8bit AVR's on their lock bit flash registers but its 10k flash writes as i assume?

Even if it were 1000 for an AVR8 why would it matter? Changing fuses and lockbits is probably something you only ever do about 2 or 3 times across the entire life of a chip.

Yes i agree but i am not sure what the "Erase entire chip" option does for the UC3 from the tool -> Programming settings on AS6 as its the default option and whats the difference with the "Erase only program area".

Does it erase the general fuses - locks by default or not? If yes what it will happen after 1000 erases when the flash has 100.000 flash writes?

js wrote:

Fuses are NOT normally erased as part of a chip erase and you only need to change the fuse only a few times in the life of the chip, maybe once only.

I assume on AVR 8bit micros it doesn't use the chip erase command which erases and the lock bit OR the chip erase command on the 8bit AVRs doesn't erase the lock bits.

The options of programming settings are common on both AVR 8bit and UC3 but that doesn't mean these options they behave the same...

My question still remains that if the "Erase entire chip" default programming settings option of AS6 for the UC3 chips uses the chip erase command and erases EVERYTHING even the lock bits which means 1000 write cycles only.

Secondly how the flash erase chip command actually works? because some pages are already ONEs (they don't have data as we don't use/write ALL the flash every time) does a flash write cycle counts for that pages or it counts only for flash pages that go from ZEROs to ONEs?

Something last i have noticed that even if i choose the "Erase only program area" and i save the solution it revert back to "Erase entire chip". I think its a AS6 BUG has anyone else noticed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can anyone help me understand the flash write cycles? UC3 it confuses me everywhere so i am going back in time for some time with enhanced AT89LP 8052's...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Diecore,

I donßt know about the write cycles but i am experiencing the same problem like you that the Fuse Register is set to 0xFFFFFFFF when i start debugging no matter what settings i have made in the memories options or Fusebits. I have am programing the register to its default value but i am stuck with this problem and cannot debug because the Bootarea is overwritten and it messes up the chips behavior. By the way i am using a UC3C1128 AVR. Any hint to solve this problem would be highly apreciated. I am using AVR Studio 5.1 and jtagICEmk2 from keeelectronics.com
It could be a AVR Studio Bug becouse it worked for me with studio 5.0 but it could also be the jtagice?! What kind of Tool are you using?