Applied power to board with no chips. Observed only 4.0 volts. Clipping diodes are very warm. The design has them backwards! They need to be inserted opposite to the silk screen. Documented as Errata #2.
- Insert U32 and U11 and check that MRESET* is around 450 msec. Should be low for approximately 450 msec after pressing reset button.
- Next insert U35, U20, U1, U25, U1, U34, U12, and 25MHz oscillator. Insert U42 and program with USB Blaster. Next we wil write a simple program in Flash that just branches to self and look at the signals on the logic analyzer. Burned Flash and looked at traces - we hang during first access to Flash. I think the problem is that DSACK0 equations in CPLD need to be negated. Will fix verilog and retry tomorrow.
Here is logic analyzer trace - it shows that DSACK0 and DSACK1 are both low all the time so logic is wrong in the verilog file - should be easy to fix.
Still having issues with address decoding - need to think some more - get 8 reads and then a bus error - so trampoline must not be working and I am not sure why DSACK1* is always low as well even if I force it high - need to check solder connection I guess too. Here is latest traces
Think I found problem - with all the other debugging of verilog code I think we took a few wild jumps and wrote to the Flash. I verified this as the Flash had FF in the first 16 locations which is not correct. I reprogrammed and bent out pin 31 which is the WR* pin of the Flash so it can not be written to. It seems to be working now - I will get traces published and then start working on the serial port.
Continue to work on debugging of wild jump problems. Have brought out my HP 16702A logic analyzer so I can get more probes on the system. Below is the setup and a current trace:
As can be seen things are loading fine up till FFF8000F and then at FFF80010 everything stops. Below is a disassembly of the code to that point:
so it is following code well - my guess is that I will have to pull on the probes and check address line A4 - it appears it is either shorted or not making good connection as that is they only thing that makes sense at this point. A4 is only connected to RAM/ROM and buss drivers. I will try that tonight and if that does not work then I will swap CPUs - I can see no reason for things to stop here unless A4 is not working?
Swapped out processor chips and see same behavior - so it is probably not a processor problem. I also visually looked at all the solder joints on cpu and flash and see no problems there and checked for short of A4 when processor was pulled and did not see a problem there. Next step is I am going to take out the trampoline code and see if I can execute from Flash at address 0.
Simple Loop is working now. Turns out needed to add some more signal logic to CPLD. Can not assume pins that are not assigned behave well. Turns out I was asserting interrupt levels even though I had not used them. By adding more logic to CPLD problem was solved. Moral to story incremental building is hazardous when you already have pins connected. Below are logic analyzer trace of simple nop loop.
Sept 20 - 24
Working on getting serial port to work - critical to rest of bring up. Have been stymied for a while but finally found the problem. The '245s on the board have the ports reversed from the assignments on the original Gryphon board but the T/R signal was not inverted. Here are the fixes which Andrew has already incorporated into the schematics of next spin.
1: U31 bend pin 1 and 19 out. Connect pin 1 to pin 20 (VCC) and connect pin 19 to pin 10 (gnd). Photo below shows fix.
2: Because the data buffers U17 and U10 are backwards this can be solved by changind the T/R (pin 1) to use RD* instead of R/W*. In the final version Andrew has reverted the buffers to the way they were in Gryphon to eliminate the gate delay that is now added. To patch bend pin 1 on U17 and U10 out and connect together and connect to to pin 4 of U11 as shown below:
With these changes serial port test scream and echo now work. Memtest which test the SRAM is now working also. HelloWorld is also working which means we can now code in C - Yay.
Next step is to get the base Gryphon Monitor up and running and then start adding devices and debugging. Next up will be the parallel port 68230 which will allow us to have timers and to test that interrupts are working.