I wonder if anyone knows how this firmware update bit works. I heard it has a limited lifespan, 100 updates. When does it get flipped?

Here is what I am doing. I am running Lejos-OSEK and to upload a program I need to put NXT in firmware update mode. Then I upload a program. When I am done for the day I just pull the battery out. Next day when I start NXT it starts ticking again. It doesn't load the old program I uploaded the day before. So I start Sam-BA and upload program again. Does firmware lock bit get changed in this case?

I don't want to ruin it.

Someone asked about this once before. Based on the discussion there, I would guess that yanking the batteries each day and reinserting them the next does cycle the lock bits. I'm not familiar with Lejos-OSEK, but it seems strange to me that you need to be in firmware update mode to upload a program. Is Lejos-OSEK some custom firmware that you are building?

Thanks! But, huh, I didn't see that info anywhere in that reply. They refered to the lock button being pushed. But when I insert the battery back the NXT boots into FW update mode.?

Maybe one of the hardware guys will chime in and correct me, but here's how I understand things: the lock bits get cycled as part of the code that runs whenever the NXT boots into firmware download mode, not as a side-effect of holding down the reset button for a few seconds. So, regardless of how the NXT is told to boot into firmware update mode (held reset button or fresh batteries after being in update mode), the boot code still runs and the lock bits still get cycled.

On the plus side, there are folks like Ralph Hempel who have cycled the lock bits many hundreds (thousands?) of times in the process of developing FW without killing them. Presumably they *will* wear out, but I don't think anybody has managed to do it yet.

--
Brian Davis

The CPU has both a security bit and 16 lock bits.

The intent behind the security bit is to prevent reverse engineering the firmware in a microprocessor. It works as follows:

• With bit set, flash memory can only be accessed during execution of firmware. You can't connect a hardware debugger to read the contents of flash memory do that you can subsequently reverse engineer the code.
• When you clear security bit, it also forces a complete erase of flash memory.

The intent behind lock bit is to prevent inadvertent erase of a block of flash memory. Each lock bit covers 16K of flash. You cannot write or erase within a 16K block if the corresponding lock bit is set.

As far as I can tell, the security bit and lock bits are not set within the NXT firmware. I know after firmware download my JTAG debugger works fine -- thus security bit is not being set. And I don't recall seeing any code to set / clear the lock bits as part of the NXT's flash based file system.

Boot mode is controlled by an external input line on the NXT CPU. Going into boot mode does not involve writing or clearing any of the security/lock bits! In boot mode an "invisible" block of ROM is made visible to the CPU memory space and this ROM contains a minimal program containing the bootstrap loader and will accept the commands for SAMBA. SAMBA is the name given to the Boot Loader. (i.e. SAM Boot Assistant where "SAM" is an Atmel CPU acronym). The NXT CPU is a SAM7S256 chip.

I am not familiar with the SAMBA commands required to load firmware. Perhaps Ralph and/or the NXJ team can comment. If the lock or security bits are set, you'd have to issue SAMBA commands to clear. I don't know if these are used as part of the NXT firmware download process because, as described above, the bits are not set.

You'd also think that when Atmel was writing the SAMBA code they would do it to minimize unnecessary erases of the security / lock bits. Atmel would certainly understand the desire to minimize erasures of these bits. If bit was already erased, then perhaps SAMBA has code to bypass the erase operation.

As well, according to the Atmel documentation, these bits are rated for 100 write/erase cycles. I can't tell from the documentation but I suspect that if a bit is already in the erased state and an erase opcode is executed then it may not count against the 100 cycles.

So it might turn out that the whole issue of exceeding the 100 cycles of write/erase on the lock/security bits is not really an issue at all. And then the "wear out" limit becomes the 10K limit on erasing a single 256-byte sector of flash.

The 10K limit is not that large. The file system VTOC is always stored as the last sector in flash. Assume two writes to it to store a file in the flash -- one to erase the existing file with same name, and second to write the new version of a file. So 5K file writes may exceed that limit. Consider a NXT used in a school or education center; 10 files writes a day may be realistic. With these assumptions, then there are possibly many NXTs that will reach the 10K limit sometime in the next year or so!

Fortuntately I understand the 10K limit is a conservative limit and I read somewhere the most common failure mode is a reduction in the 40-year retention of flash contents and not an error in writing.

I'm not really a hardware guy. It's possible I might have got some of the details wrong.

Every time the NXT is put into SAMBA mode it involves a cycle of the lock bit. The SAMBA code in the ARM chip does the locking and unlocking itself. This was well described on Lugnet a long time ago. Each time you put the NXT into "boot" or firmware download mode (either via pressing the reset button for more than 3 seconds or by using any firmware download utility to reflash the NXT firmware) you have caused the lock bit to be cycled.

Flemming Bundgaard, from LEGO, ran two or three test-to-failure runs with my NXTTools utility repeatedly setting the brick into firmware download mode and downloading the standard NXT firmware to the brick. In each of his tests the brick failed, if I recall correctly, after ~7000-8000 iterations. There is no doubt that if you put your NXT into boot mode somewhere in the neighborhood of 8000 times your brick will no longer accept a new firmware download. You can test this yourself if you like using NXTTools undocumented iteration count switch and a brick running on an external power supply. Each iteration takes about 30 seconds so the test will run for ~67 hours. Of course, your brick could have a different lock bit lifespan than Flemming's bricks had. It is also worth pointing out that if you reflash or reset your NXT once a day 365 days a year it will probably take you almost 22 years to wear out your lock bits. If you do it 10 times a day, everyday, then your brick should last 2.2 years.

John Hansen

Hi,

I am the developer of LEJOS OSEK, so I have to put some comments. This thread is very helpful
to understand the details of the firmware upload. In case of LEJOS OSEK, there are two ways to
run the firmware (+ application) on the NXT.
1. Run the program on SRAM of ATMEL ARM7
2. Run the program on FLASH of ATMEL ARM7
In the case1, ATMEL SAM-BA does not say anything about the lock bit during the program upload.
In the case2, ATMEL SAM-BA asks about the lockbit during the program upload.
Judging from the above behavior, I thought that if the program was uploaded into SRAM, this would not
affect the lock bit and this is the way which I instructed in LEJOS OSEK, but if it was not true, I should consider it. Please let me know any comments.

One solution is to augment the built in bootloader (SAMBA) with another boot loader in the first 16K of the flash, which will either load firmware into the rest of the flash or into RAM. The main requirement for this is the ability to remap the interrupt vector. Other ARM7 processors have this ability but I am not sure if the NXT's processor does. This will remove the need to go into SAMBA which toggles the lock bit.

But as John suggested, this is only relevant for very heavy use in schools.

I am not an English native, so I am still confused about this topic. When a LEJOS OSEK program is uploaded into SRAM of a NXT. The following
TCL script example is used:

send_file {SRAM} "C:/cygwin/lejos_osek/samples/HelloWorld/helloworld_samba_ram.bin" 0x202000 0
go 0x202000

This means that SAM-BA uploads the binary program (helloworld_samba_ram.bin) into 0x202000 address in SRAM and the Program Counter is
changed to 0x202000. Then an application starts running. In this case, if the NXT was turned off, the application program could not run anymore.
So you need to upload the program again to run the program. In this case, NXT still keeps being in SAM-BA mode. (the famous beeps are still on while the application is running)

My understanding on this topic is that:
- The above program upload process itself does not affect the lock bit.
(When NXT was already in SAM-BA mode, even if removed and attached the battery, it would not affect the lock bit because NXT was already in SAM-BA mode)
- But, if NXT was reset or turned into SAM-BA mode from normal mode, it affects the lock bit.

If I was wrong, please correct me.

So long as you never leave SAMBA mode you are not affecting the lock bits.

John Hansen