Technological Arts  4/19/99
www.technological-arts.com
support@technological-arts.com
 

TROUBLESHOOTING X68C75-BASED ADAPT11 BOARDS

Here are some typical symptoms, their possible causes, and suggested resolutions, for problems encountered with X68C75-based boards:

1)    Frequent errors with PCBUG11, or failures with ICC11 and DOS batchfile downloading.
    -this can be caused by noisy communications.  To see if this is indeed the case, try removing your board from any breadboard or other circuit in which it is plugged.  If the problem is resolved by doing this, put a 10K pullup resistor on the TX pin of the 50-pin header (ie. 10K resistor between pin 5 and +5V).  The reason this is necessary is that the internal pullup resistor of the RS232 interface chip is too high a value to overcome the stray capacitance of your system, and the resulting RC circuit is distorting the serial data stream being sent by the 68HC11 to your PC.
    One other possibility is an intermittent connection in your serial cable.  Do a continuity check of the RX, TX, and GND connections between the 9-pin D-sub connector and the 4-pin Molex.

2)    Failure to load new program into X68C75 EEPROM.
    -the Xicor chip can be rather troublesome at times, so a little patience & understanding is required.  PCBug11 is the best tool for diagnosing your problem.
    The first thing you should do, once you have PCBUG11 running, is to display the contents of the X68C75 register block.  (ie.  type MD $8400).  You should see a value of $5E at $8400, followed by mostly zeroes in the other locations.  (Users of Adapt11C75DXE will examine $0400 instead, and should see $7E).  If you see a lot of other values (typically FF, EF, or BF), it means your Xicor chip's internal state machine is not properly reset.  To reset the state machine, make sure the WRITE PROT switch is in the PROT position, remove power, and re-apply power.  Re-establish communication with PCBUG11 (by typing RESTART, if you haven't quit already), switch on the 'HC11 expanded mode bus (by typing MS $103C $E5), and check the Xicor register block contents again.  Try the same procedure again, if necessary.  Once you see mostly 00, then you can be confident the state machine is properly reset.  (BTW, the improper reset state typically
shows up when you have applied power while the WRITE PROT switch is in the WRITE position.)  A good rule-of-thumb with these boards is to power down and then back up (with switch at PROT) after you perform some operation (such as download, turning off SDP, etc.).  This puts the state machine in a reset state.
    The next thing to do is establish that the EEPROM of the X68C75 can be altered (ie. establish that Software Data Protection (SDP) is not on).  To do this,
attempt to modify an EEPROM location.  For Adapt11C75,  Adapt11C75DX, and Adapt11C75DXR, any location from $E000 to $FFFF will be an appropriate
candidate.  For Adapt11C75DXE, use an address between $6000 and $7FFF.  For the purposes of this example, we will assume an Adapt11C75DX board, and
use $E000.  For the memory to be alterable, you should now move the switch to the WRITE position.  Enter MM $E000, to which PCBUG11 responds with the
contents of that location.  Enter a new value (other than what is displayed), and hit ENTER.  If you receive an error message, you can conclude that SDP is on, or
the X68C75 Block Protect bit has inadvertently been set (a very remote possibility), or that there is a communication error (see item 1, above).
    If you concluded that SDP is on, you need to use the DOS batchfile SDPOFF1 or SDPOFF2 to disable it (as per your Starter Package Manual).  Keep in mind the rule-of-thumb mentioned above concerning powering up and powering down with the switch at PROT.  Once you've run the batchfile, get back into PCBUG11 and go through the above steps of checking the register block contents at $8400, and again attempting to modify an EEPROM location.  If the contents still won't
change, go through the SDPOFF batchfile routine once more.  This may sound like a real pain, but once you have SDP off, the chip behaves rather well.



We ship all boards with SDP off, so you shouldn't normally have to worry about it.  However, there are some ways that SDP can inadvertently get enabled:
    - using the X68C75 bootstrap option setting in ICC11 V4.5 (there is a bug in the downloader--  use the external EEPROM setting instead, once you've
established that SDP is off). Version 5 of ICC11 for Windows does not have an X68C75 option--  instead you would use the External EEPROM setting (of
course SDP has to be off for this to work).
    - using the BPOFF1 or BPOFF2 batchfiles.  Every time you execute a special state machine sequence in the X68C75, it automatically switches SDP back on.
So running these batchfiles to clear the block protect bits will re-eanble SDP, and you will then need to run SDPOFF again.  Since the state machine implemented in the X68C75 carries out its actions as "open-loop" operations, there is no status register you can read to verify the result of a state machine command you just
executed.  The only way to verify that the action worked is to check the results with a tool such as PCBUG11 (ie. are you now able to MM to modify EEPROM
locations?).  This "open-loop" system, unfortunately, is an industry standard for EEPROM and Flash chips.
    -using a third-party utility, such as Sylvain Bissonnette's HCLOAD.  When using the X68C75 tools in HCLOAD, keep in mind that any function which alters the
SFRM register, the BPROT register, or the EEM will automatically re-enable SDP, so the last thing you should do before exiting is turn off SDP.
    -if you didn't get you X68C75 chip from Technological Arts, it probaly has the factory settings of SDP enabled, with the register block mapped to $0400.  If you try to use our SDPOFF batchfile, make sure you have the latest version (on our website Tech Support page).  The old version (from more than a year ago)
assumes the register block is at $8400, and won't work if it isn't.  The newer version actually searches the chip to find the location of the register block.


    Once last comment:  it is really quite rare that a Xicor chip actually gets blown (if so, it usually gets hot);  instead, following the steps above is likely to lead to a
resolution of the problem.  If you still can't get your X68C75 to work after following all the above advice, send the chip (and board) back to us, and we'll attempt to diagnose the problem for you.