Thu Jul 19 13:54:04 CEST 2007

the boot block


* BLOCK 0 = empty OR 0000 and 0006 contain jumps to BLOCK 1 (soft reset)

  this ensures that an empty boot block is valid + interrupts and
  application invocation result in a reset when they are not defined.

* during boot, a DEBUG condition is checked. this will force it to run
  the interpreter to await commands.

* if the DEBUG condition is false, the application (addr 0002) is
  executed. if there's no application, a soft reset is run. (so
  eventually the chip responds).

* installing a new application:
   - clear boot block
   - install security jumps
   - install isr code

* possible conditions:
   - a pin
   - a boot wait + serial activity
   - break condition on serial port


installing the bootblock can be done in a single interaction macro:
compile an init macro, then when this succeeds wipe bootblock, and
upload a new one.

the deal is that the boot sequence up to the DEBUG check is NEVER
changed! it's not enough to have your application perform such a
test. this can go wrong in it's boot sequence before the check is
executed, or even during the check. get it right once, then keep it
like it is.

another possibility is to have the serial port operate from
interrupt. that way sending a break signal could actually stop the
program. however, this is more complicated and reduces freedom for
custom isrs.


thinking about it, why the one at 0006 ?  ok, it prevents problem if
there's a reset vector but no application vector installed. better to
be safe.

ok, default really is empty boot block: means app is gone. whenever
APP and ISR vectors are installed the 'reset-vector' macro needs to be