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