| |
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
|
|
|
