...he had been trying to update his TINI to 1.0 and wound up in a pickle with an erased TINI (DSTINI 0014A ES 115059), and inability to boot from his Atmel flash chip (AT29C010-70JC) into which he'd programmed the 8024 loader.

Here's what I did to try to analyze the situation and restore his TINI. The questions we had were:
1) why couldn't he boot the AT29C010 flash with the 0824 loader in it?
2) is there something odd about the Atmel AT29C010?

We test every STEP+ with a flash device in the socket so we were confident the board worked when shipped from Systronix. Also he could boot a good TINI, then install the external flash jumper and see what appeared to be valid boot code in the 29C010, so why wouldn't it boot?

TINI uses an AMD 29C040B-55 which is a 512Kx8 55 nsec flash device. The 29C010-70 is a 128Kx8 70 nsec device. Aha that's the answer - 70 nsec is too slow for TINI. But since we have the hardware here, let's restore the device and test it before sending it back to our customer.

• JavaKit 2.1.7 which comes with TINI 1.0, a straight serial cable to a STEP.IR board (just because that's what I have on my desk at the moment). I could be using a regular STEP+ which has the external boot flash socket.
• Tek TDS220 digital scope, just because it's also on my desk at the moment
• PC with NT4, SP5 and JBuilder 3.5 which includes the Sun JDK1.2.2
• My brain, which should be the most important debugging tool (but is sometimes the biggest debugging impediment).

1. First, I installed his erased TINI in a known good STEP board, booted an external flash loader (previously loaded in an Atmel AT49F010-70JC), and it came right up. So the TINI hardware is OK. Now the erased TINI is running the 0824 loader in its internal C390 RAM, having copied it on power up from my external flash device. With the external flash jumper in place, TINI is accessing the external flash device (but not executing from it, other than briefly on power up before it copies the loader into the C390 internal RAM).
2. Then I removed the external flash jumper. Now TINI continues to run the boot loader from the C390's internal RAM but it can access TINI's on board flash device.
3. I did a B0 (bank 0) and D 0 100 (dump address 0-100) and sure enough, TINI's on-board flash is erased - all FFs.

1. Next I installed the returned TINI (which we just showed has an erased boot loader but is otherwise OK) in the returned STEP+ board, with my 0824 loader in the external flash socket and the external flash jumper installed. It boots OK. So the STEP+ board is also OK, as is the flash socket.

1. Boot up the erased tini using my 0824 loader in external 55 nsec flash.
2. Remove the external flash jumper. Now the 0824 loader is running out of the C390 internal RAM, and can access TINI's on-board flash device.
3. Execute a T3 to unlock TINI's on board flash boot sector (it's erased already, but this is normally a dangerous operation).
4. Execute a Z0 to erase the flash boot sector in TINI.
5. Execute an M to copy the 0824 loader from internal C390 memory to TINI's flash boot sector.
6. Remove the external flash jumper and click reset in JavaKit. The newly restored 0824 loader boots up from TINI's on-board flash. It's no longer erased.

1. In JavaKit, select the menu option File->Update Loader and browse to tini1.0\bin\loader0515.hex, select it and the loader will be updated, and TINI rebooted automatically. There are more detailed instructions and screen captures in the Beta 3 tutorial, which was the first release to use the 0515 loader.
2. Now load the tini.tbin and slush.tbin files using File->Load File in JavaKit.
3. TINI now has the 0515 loader, and new 1.0 firmware API and slush.
4. If the heap is not cleared there may be problems so in the loader, execute a B18 and F0 to erase any old data there.
5. Enter the E command to boot up slush.
6. Configure the IP address so that you can send TINI some application.

For the really curious, boot loader source code is available, along with some documentation.

The boot loader is located in flash bank 0 starting at address 0. All 8051s (including the 80C390 used in TINI) must start execution at location 0, the so-called "boot vector". Typically the instruction located here is a jump over the interrupt vector table which is also in low memory, starting at 03H.

Soon after the loader boots up, it copies itself into the internal RAM of the C390 and executes out of there. A reset or power cycle will wipe out this internal code and cause the controller to again execute at the boot vector in low memory.

The easiest way to get a copy of the loader HEX code is with a dump from a known good TINI. If you don't have a good TINI, here's a copy of the loader HEX code for loader version 082499, which works through TINI Beta 2.2. The current release of TINI (June 2000) is 1.0, but you can use the older loader to boot TINI up and then convert or upgrade it to the 1.0 loader.