Thu Feb 12 09:05:16 CET 2009

fixing bugs w. bitbanged serial

Maybe I should switch to a proper bit-banged serial port
implementation first.  However, without knowing what exactly is
happening, I can't make proper decisions.

The hypothesis is that there is some transition on the host->target
line that gets mistaken as data.  I don't have anything to measure
this, but I can build something to measure it.

One possible route is to fix the logic analyser such that it is
connected with the ICD2 serial port for serial console, and the TTL
serial port for data transfer.  This does look like a lot of work..

Alternatively, we could try to get the PK2 logic analyser to work.  It
has higher bandwidth.  I do have two of them..  The problem is that it
has only a window of 1K samples for 3 channels..

So I do need my own, as I don't know yet what I'm looking for.  Let's
build it.

Next problem: there seems to be something wrong with chip erase.. I
can program fine, but it won't reset the bits before programming.

Ok. There was at least something wrong with the SetAddress script.

Now I get into trouble when I try to run
  (EXECUTE_SCRIPT (ConfigWrPrepScript))

car: expects argument of type <pair>; given ()

The other problem, when I (execute ProgMemWrPrepScript) the programmer
hangs.  The script that hangs is 18F_PrgMemRd64, but the writing seems
to have succeeded.

It doesn't behave the same on subsequent runs..  Something fishy going
on here..

adding (READ_STATUS) after each read/write command seems to do the trick.

No.. back to square one.  It won't verify if I change the source file,
both for config mem and program mem.

One thing that needs to be on is external reset.  It should be
possible to do this with turning target off though..