 | | | | | | |
| |
|
Does anyone know how the NXT firmware handles writing program files into flash?
If you re-flash a program with the same name, does it first erase the sectors
that the old program was located in and then re-flash these sectors with the new
program? Or, does it write the new program (with the same name), to a different
set of sectors and then erase the old program?
The flash used in the NXT which is internal to the AT91SAM7256 microcontroller
can be re-programmed 10,000 times according to the spec.
Let's say that a heavy user flashes the part 200 times per week. I know that
some people will exceed this while others will be lower. If the NXT firmware
erases and re-writes the same area, this user would exceed the number of cycles
in 1 year. Probably, most people will be OK, but the heavy users who may even
exceed 200/week will be very disappointed.
I'm hoping that Atmel's 10,000 number is conservative. I also hope that the NXT
firmware doesn't reprogram the same location. If I'm working on a program and
reflashing it many times, I think I'm going to keep changing the name so it gets
stored at a different location until the flash is full, and then erase and start
over.
Any knowledgeable people out there in this area?
David Wallace
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, David Wallace wrote:
> Does anyone know how the NXT firmware handles writing
> program files into flash?
I don't; John Hansen might. While Flash memory does have a limited number of
read/write cycles, it appears that the stated limit is conservative, by a large
margin... although some of us have thought about a "test to failure" trial, I've
not been willing to subject my NXT to such destruction, but I think others may
have tried, and failed, to overuse the Flash memory. So no promises, but
statisticly speaking it looks like your milage will exceed the chip
manufacturers limits.
A more important problem may be the lock bits for the bootcode, as these in some
situations need to be toggled for firmware uploads, and they "wear out" much
quicker (guarenteed for IMS 100 cycles?). But again, I know firmware developers
who have toggeled them close to that already, without problems, so perhaps those
are overspeced a good bit (byte?) too.
> Let's say that a heavy user flashes the part 200 times per week.
I've written NXT-G code that has done more than 200 writes in a single run
(using the file system to implement arrays... and yes, I've got one better way
for small arrays already, and ideas for a much better implementation... soon.).
> I also hope that the NXT firmware doesn't reprogram
> the same location.
I suspect it does. I say that for two reasons, neither iron-clad. First, keeping
track of how frequently each sector of Flash is used is probably not something
you worry about when developing compact firmware for a toy. Second, if you keep
downloading the same-named NXT-G program after editing it (again and again), it
does not fill up the memory of the NXT with a bunch of "ghost images". And for
downloading programs, I seriously doubt it matters. As far as downloading
programs, I seriously doubt even "heavy users" will come anywhere near flashing
the entire memory 200 times a week (as far as using flash as extended file
memory for program bookkeeping, you could, but not downloading programs). All I
do to try to equalize flash usage is not delete anything until the NXT has a
full memory... at which point I normally use the "delete everything" option to
clean out the entire memory at once. That way, I'm at least spreading out the
flash usage.
> Any knowledgeable people out there in this area?
Yeah, who wants to be the first to test an NXT to destruction :-) ?
--
Brian Davis
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, David Wallace wrote:
> I'm hoping that Atmel's 10,000 number is conservative. I also hope that the NXT
> firmware doesn't reprogram the same location. If I'm working on a program and
> reflashing it many times, I think I'm going to keep changing the name so it gets
> stored at a different location until the flash is full, and then erase and start
> over.
When downloading a program to the NXT using NBC if there is a file with the same
name on the NXT already it is first deleted. Then a new file is created and
written using the same filename. I don't know whether that means the firmware
will write the file to a different location or not.
Executables and icon files have to be created using OpenWriteLinear which means
they have to be contiguous. The VM actually reads the byte codes directly from
flash as the program executes.
There was a discussion some time back in which, if I recall correctly, it was
said that the NXT firmware doesn't do anything fancy, like wear leveling, for
the flash memory.
> Any knowledgeable people out there in this area?
Dick Swan comes to mind, but it may fall under the category of protected
intellectual property.
John Hansen
| | | | | | | | | | | | | | | | | | | | | |
| |
|
> John Hansen wrote:
>
> > Any knowledgeable people out there in this area?
>
> Dick Swan comes to mind, but it may fall under the category of
> protected intellectual property.
I researched this topic about eight months ago. I no longer worry about
it. I must admit I didn't know about the "lock-bits" specification and
was concerned only with the "flash rewrite specification".
I have also had other conversations on this topic which unfortunately
are covered by NDA.
Here's some public domain information tidbits that are relevant.
1) Limit on flash memory cycles is across the complement of extreme
temperature ranges and voltage battery levels of the device. I double it
anyone intents to operate their NXTs at these temperature extremes.
2) I never kept the web reference, but there was a similar question
posted in a newsgroup for a robotics design contest that was held a few
years back. The contest product used an Atmel AVR series CPU.
There was a response from an Atmel Support Engineer -- his reply was
along the lines of "our specs are conservative", "specs are for
temperature extremes". The most interesting comment was "the main
failure mode is a reduction in the data retention time". I think most
NXT users are willing to accept a reduction in the 40-year data
retention specification for flash.
| | | | | | | | | | | | | | | | | | | |
| |
|
In article <J5C97r.BBF@lugnet.com>, David <dww.robotics@gmail.com>
writes
>
> The flash used in the NXT which is internal to the AT91SAM7256 microcontroller
> can be re-programmed 10,000 times according to the spec.
This is the guaranteed minimum number, with higher voltages and at
higher temperatures than you are likely to use the NXT at.
FLASH memory is a pretty mature technology now, with 20 odd years
shipping in products. It is pretty well understood by the manufacturers
how to characterise it.
If you get less than a million write cycles I would be very surprised.
I would also guess that you are either at the Antarctic or in a tropical
rain forest.
> I'm hoping that Atmel's 10,000 number is conservative. I also hope that the NXT
> firmware doesn't reprogram the same location.
I expect the NXT does not do anything fancy. It is not worth the effort
in consumer devices, if it lasts two years of heavy use there will be no
warranty claim. There is also the issue of whether your wear-levelling
program is sufficiently reliable.
Cheers,
Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
| | | | | | | | | | | | | | | | | | | | |
> > Tony Naggs said on September 10, 2006 6:11 AM
> >
> > I expect the NXT does not do anything fancy. It is not worth the
> > effort in consumer devices, if it lasts two years of heavy use
> > there will be no warranty claim.
Don't forget that the education market is also a large portion of the
Mindstorms market. Lifetime for education is more line ten years?? And
depending on environment, these could be heavy use applications.
LEGO has also been very generous in their replacement policy. [Anyone
else got a motor of unknown vintage replace for free with no questions
asked).
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, David Wallace wrote:
> Does anyone know how the NXT firmware handles writing program files into flash?
> If you re-flash a program with the same name, does it first erase the sectors
> that the old program was located in and then re-flash these sectors with the new
> program? Or, does it write the new program (with the same name), to a different
> set of sectors and then erase the old program?
>
> ...
>
> Any knowledgeable people out there in this area?
>
> David Wallace
One probable reason that the NXT does not do any wear leveling is that it
executes instructions directly from flash (the instructions in the firmware
itself), which is memory mapped. This requires that these instructions are
contiguous, which makes wear-leveling difficult or impossible (this is called
XIP in some of the technical literature, for execute-in-place).
The instructions of NXT bytecodes are not machine instructions, so it would
probably be possible to move their blocks/pages around the flash, to level the
wear, at least around the areas that are used by files, not by firmware code.
This would make the cost of reading a word from flash a bit more expensive (to
do the logical-to-physical page traslation), but for 256-byte pages, it would be
just a tiny bit slower. Not much. There would be some waste of space for
headers, to be able to reconstruct the mapping at boot time.
I disagree with ealier posts that wear leveling requires counting erasures. It
can also be done very effectively by randomly swapping pages at some fixed low
probability. It's not very hard to implement good wear leveling.
If anybody would like to build wear-leveling into the firmware, I'll be happy to
supply relevant pointer and help.
But I do agree with earlier posts that wear leveling is probably not that
useful. As long as wear is caused by a person clicking on the "download" button,
it will be hard to wear out the flash on the NXT. But if you write a program
that reads data from sensors every few ms, writes that to the same file over and
over again for hours or days, then you might discover what the actual endurance
limit of the flash is :-)
Sivan Toledo
| | | | | | | | | | | | | | | | | |
| |
|
"Sivan Toledo" <stoledo@tau.ac.il> wrote in message
news:J5DMMp.Bs5@lugnet.com...
> One probable reason that the NXT does not do any wear leveling is that it
> executes instructions directly from flash (the instructions in the • firmware
> itself), which is memory mapped. This requires that these instructions are
> contiguous, which makes wear-leveling difficult or impossible (this is • called
> XIP in some of the technical literature, for execute-in-place).
True, you can't level the firmware - only file systems can be wear leveled.
I understand that there has been discussion concerning the SAMBA (Boot
Assistant) and the NVM lock-bit locking/unlocking limit of 100 cycles.
Surely the lock bits aren't being unlocked with every firmware download -
are they?
I have written flash loaders for cell phones (a few years ago), and what I
remember is that there is a boot sector that is meant to contain basic code
for configuring enough hardware to allow flashing and providing routines to
write to and read from memory. We called this the ROM bootloader.
The boot code that we wrote would wait for one or two character commands
from a PC. If it didn't get a command within a second or two, it would jump
to the firmware start address. We would send commands to download a RAM
bootloader (from the PC) which had routines that would do the flashing (i.e.
firmware download).
The boot sector is not meant to be changed. It is a simple program. In fact,
there used to be flash devices that would only let you lock it one time. The
100 cycles is a big improvement and way more than enough. Subsequent
firmware downloads did not require unlocking of the boot sector. The RAM
bootloader would flash to the non-boot sectors.
The part I don't understand is why a boot sector has to be unlocked to do a
firmware download. I read the AT91SAM7S256 spec sections on booting and it
sounds like there is a ROM boot program which jumps to the SAMBA boot loader
after setting up hardware and communication mechanisms like USB. The SAMBA
loader is in the first two flash sectors. It then copies itself to RAM to do
the firmware download. I assume it does this so that it can overwrite itself
in the first two sectors.
Does the NXT firmware have a bootloader that is locked in the first couple
of sectors? And if so, why would it be required to be unlocked?
Forgive me if I have misinterpreted what may have been previously discussed,
or if this issue has already been discussed and resolved.
Dave
| | | | | | | | | | | | | | | | |
David Wallace wrote:
>
> Does the NXT firmware have a bootloader that is locked in the first couple
> of sectors? And if so, why would it be required to be unlocked?
As I understand it, the lock bits are only touched if SAMBA mode
is entered, which is done when the reset button is pressed for more
than about three seconds.
At that point, the ARM erases the bottom two sectors and installs
the SAMBA firmware into FLASH and locks the lock bits. Argh.
The LEGO firmware can then be loaded, and I believe it contains
a SAMBA compatible firmware downloader too, but it leaves
the lock bits open.
Ralph
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, Ralph Hempel wrote:
> David Wallace wrote:
> >
> > Does the NXT firmware have a bootloader that is locked in the first couple
> > of sectors? And if so, why would it be required to be unlocked?
>
> As I understand it, the lock bits are only touched if SAMBA mode
> is entered, which is done when the reset button is pressed for more
> than about three seconds.
>
> At that point, the ARM erases the bottom two sectors and installs
> the SAMBA firmware into FLASH and locks the lock bits. Argh.
>
> The LEGO firmware can then be loaded, and I believe it contains
> a SAMBA compatible firmware downloader too, but it leaves
> the lock bits open.
Whether you reset the brick or just run the download firmware routine in the
LEGO Mindstorms NXT software or in RobotC or in NBC/BricxCC you've put the brick
in SAMBA mode (clicking brick mode) and the lock bits have been cycled. But I
have heard from a very reliable source that ATMEL has measured lock bit
read/write cycles at up to 7500 under normal temperature conditions (they just
don't guarantee that many under all conditions).
I could write a little test program which would repeatedly boot the brick into
firmware download mode, download the firmware, then repeat if anyone would like
to see how many times it can go through that cycle before the lock bits quit
working.
John Hansen
| | | | | | | | | | | | | | | | | |
| |
|
> > John Hansen on September 11, 2006 10:58 PM wrote:
> >
> > I could write a little test program which would repeatedly boot
> > the brick into firmware download mode, download the firmware, then
> > repeat if anyone would like to see how many times it can go through
> > that cycle before the lock bits quit working.
I guess it depends on which way they fail? Do they fail in locked mode
or in unlocked mode? If, as would be good design, they fail to
permanently locked, I'd guess nobody is interested in trying.
What nobody has mentioned yet is the following:
After downloading firmware, the lock bits are left in unlocked mode.
This is good.
I strongly suspect that erasing locked bits that are already erased
doesn't count in the count of "how many times can I erase this".
This is based on 25-year old knowledge from building a bit-banged flash
erase and programmer for first generation EPROMS. With these you pulsed
the flash erase line while applying 12V power. To do a single "erase"
pulse. To erase a flash sector you sent one erase pulse and then checked
to see if everything was erased. If not you continued looping. When
flash was new it might only take 5 to 10 times through the loop. As it
aged with more erases, it took more pulses to do a erase. When you
reached 50 to 80 erase pulses you discarded the flash because it was
worn out.
Modern flash have the erase built-in and I'm sure use a different
technology. But I expect the keep pulsing until erased may still be
valid.
So I suspect if locked bits are already erased there is no "strain" on
the contents if you do another "erase". If this is the case, exceeding
write cycles on "lock bits" is not an issue.
Hopefully, there are more knowledgeable and up-to-date hardware
designers who may want to comment.
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote:
>
> After downloading firmware, the lock bits are left in unlocked mode.
> This is good.
>
> I strongly suspect that erasing locked bits that are already erased
> doesn't count in the count of "how many times can I erase this".
[...]
> So I suspect if locked bits are already erased there is no "strain" on
> the contents if you do another "erase". If this is the case, exceeding
> write cycles on "lock bits" is not an issue.
According to what I have read, putting the AT91SAM7S processor in system
recovery mode (i.e., by resetting it via the hardware reset button or by
programmatically putting it into firmware boot mode) loads SAM-BA into flash and
when SAM-BA is loaded into flash memory it unlocks the first two pages of flash
memory and then it relocks those two pages. When you then download a firmware
to the NXT the first two pages of flash are unlocked and they remain unlocked.
So each firmware download results in a cycle which changes the lock bit state
from unlocked to locked and then from locked to unlocked. If the cycle limit is
7500 cycles then it probably isn't a big deal It would be a huge deal if they
failed after 100 cycles.
If they ever do fail in the locked state then you would have a permanently
clicking brick.
John Hansen
| | | | | | | | | | | | | | | | | |
| |
|
> According to what I have read, putting the AT91SAM7S processor in system
> recovery mode (i.e., by resetting it via the hardware reset button or by
> programmatically putting it into firmware boot mode) loads SAM-BA into
flash
Are you sure of this John? It seems like the reset button would be for dire
circumstances and would do something different than the firmware boot mode.
The spec says this about SAMBA loading:
"To enter SAM-BA Boot Recovery, the TST pin and the PA0, PA1 and PA2 pins
should be tied high."
I would assume that this is what the reset pin does. Although, maybe it is
firmware controlled since there is the > 3 sec hold time.
> when SAM-BA is loaded into flash memory it unlocks the first two pages of • flash
> memory and then it relocks those two pages.
Do you know why it does this? The spec says that SAMBA copies itself into
RAM and runs from there. I'm sure this is done so that it can overwrite its
flash image with the firmware being downloaded. However, I don't understand
why it would relock the first two sectors unless it assumes that there is a
user boot program in the firmware download.
> But I have heard from a very reliable source that ATMEL has measured lock • bit
> read/write cycles at up to 7500 under normal temperature conditions
If this is true, I vote we all shut up - or maybe I should just shut up :-)
David Wallace
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, David Wallace wrote:
> > According to what I have read, putting the AT91SAM7S processor in system
> > recovery mode (i.e., by resetting it via the hardware reset button or by
> > programmatically putting it into firmware boot mode) loads SAM-BA into
> flash
>
> Are you sure of this John? It seems like the reset button would be for dire
> circumstances and would do something different than the firmware boot mode.
I am not 100% sure but I am pretty sure based on a number of discussions that I
have been involved with during the MUP2/MDP. To the best of my knowledge a
clicking brick (however it got into that state) is a brick running SAM-BA in
flash with the first two pages locked.
> > But I have heard from a very reliable source that ATMEL has measured lock bit
> > read/write cycles at up to 7500 under normal temperature conditions
>
> If this is true, I vote we all shut up - or maybe I should just shut up :-)
Last night I used a new version of NeXTTool (with an undocumented command-line
switch) to cycle the firmware 110 times on my oldest brick which has already
been cycled a bunch of times. It still works. I don't recommend you try it
yourself. It takes about 30 seconds per cycle so running it through 7500 cycles
will take a while.
John Hansen
| | | | | | |
