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