I may need to introduce you to the Underhanded C Programming Contest!

I visit that page now and then. Some really good (and amusing) code gets submitted.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I spent yesterday afternoon at the bench bolting POC V2 together. I have a procedure in which I add a certain number of passive components, check for faults, add some more passive components, check for more faults, and when all passives are installed, apply power to see if something is going to go "bang"—such as an electrolytic that is in backwards (been there, done that ). This initial test is with no active components installed.

The first power-up went okay and the shop was not filled with vile-smelling smoke. With that out of the way, I installed the two DS1813 econo-resets and applied power again. I can see /RESET being held low and then released at power-on, as expected. Shorting the NMI header caused /NMI to go low and then return high, also as expected. So far so good.

That is as far as I have gotten as of right now. Working with vision in only one eye makes for some...ah...interesting challenges, as I have no close-up depth perception and sometimes just can't seem to get components leads and socket pins to go into their respective holes. Progress tended to be slow, but I just plugged away at it until it was done.

Next step will be to install the Ø2 clock oscillator to check for the presence of a Ø2 clock signal at the MPU and CPLD. Assuming the clock is running, I'll install the CPLD, hook up the JTAG port to my PC, power the unit and see if I can read the CPLD's contents, which I had previously programmed in the Atmel test rig. A successful test will prove that the JTAG port is working and the CPLD is functional.

Here's what POC V2 looked like last night as I was doing the second power test. The two DS1813's are installed (extreme right side of the board in TO-92 packages).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I meant to post the below picture earlier but forgot.

During the firmware development for POC V1, I had the original ROM socket go bad from repeatedly removing and installing the EPROM. Not wanting to again have to go through the agony of replacing a 28 pin socket, I positioned V2's ROM so there would be sufficient room to insert a ZIF socket into the permanent socket. The below picture shows the ZIF socket in place, along with the SCSI host adapter. It all fits—barely.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just glad to hear you're able to make progress on this thing BDD.

Bit by bit (no pun intended) it'll get done.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The two clock generators (Ø2 and the UART's clock) check out, although Ø2 has some ringing on the leading edges (the UART's clock is clean). I'm debating as to whether to add some termination to the Ø2 circuit to see if it will suppress the ringing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The next step in getting POC V2 up and running was to see if the JTAG port worked. The plan was to program a CPLD (Atmel ATF1504AS) in the Atmel test rig, install it in POC V2 and do a verify on it. If the verify operation succeeded then that meant the Atmel ISP software was able to read the CPLD while installed in POC V2, proving that the JTAG port was working.

After programming the CPLD, I installed it into its socket on POC V2, connected the JTAG cable and powered up.

At the risk of stating the obvious, the JTAG cable is that 10-conductor, grey ribbon cable hanging over the left edge of the desk—the CPLD is immediately to the right of the JTAG port. The cable that ships with the Atmel test rig is relatively short. As the JTAG interface doesn't run real fast a much longer cable can be used without compromising reliability. I made up a six-foot (1.83m) cable so it would reach from the back of my PC to the desk where POC V2 was waiting.

The power indicator on the Atmel programming adapter (plugged in the the PC's Centronics port) illuminated, which was a good sign—the adapter gets its power from the JTAG port on POC V2.

The next step was to fire up the AtmelISP software and tell it to verify the CPLD against the JEDEC file from which it was programmed while in the Atmel test rig. AtmelISP reported that verification was successful, proving that the CPLD could be accessed through POC V2's JTAG port.

With this out of the way the next step will be to finish populating the board, burn an EPROM with some test code and see if she'll "go or blow."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Fingers crossed!

Just watch for a mushroom cloud in the vicinity of Chicago.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Well, POC V2 is bolted together and when power is applied it doesn't blow. However, it also doesn't go. Resets are working, I have clocks and I do see bus activity. However, there is no visible sign of life beyond that.

Thinking that my adaptation of POC V1's firmware might wrong (there is one possible "gotcha" involving the QUART that I need to examine), I wrote a very simple program that puts the 65C816 in native mode, initializes the stack pointer, loads the QUART's registers with enough information to enable communication on channel A and then writes a couple of characters to the transmit FIFO. This is essentially the same code I used to bring POC V1.0 to life for the first time. Still nothing. So I modified the code to not put the '816 into native mode and tried again. Again, nothing.

So the problem apparently lies deeper. Some possibilities come to mind:

1. Incorrect voltages at the console serial port. Tested and eliminated.
   
   
2. Defective ROM. Not likely, as the EPROM burner can read and verify the ROM against the object file used as the code source. Just to be sure, I tried a different ROM.
   
   
3. Defective CPLD. Programming another CPLD produces the same results, so it's unlikely there's a hardware issue with it.
   
   
4. Defective QUART. Unfortunately I only ordered one, so I can't swap it for another right now.
   
   
5. MPU not seeing valid code at power-on. Firmware is supposed to be mapped in at $00E000-$00FFFF at boot. It may be that it is not showing up where it should be, because:
   
   
   1. The firmware is burned to the wrong place in the ROM.
      
      
   2. The CPLD is mapping the ROM in at the wrong place.
      
      
   3. The CPLD is not mapping in ROM at all and the '816 is randomly executing garbage bytes in RAM as code.
   
   
6. Defective MPU. Tested and eliminated. The '816 works in POC V1.1.
   
   
7. Bad RAM. Nothing in the test firmware touches RAM—each fetch or store instruction is an immediate load from ROM or a write to a a QUART register.

One of the handy things about POC V2 is it is 100 percent static. So it should be possible to single step the clock in both phases to try to identify the problem. Accordingly, I am going to build a little gadget to plug into the Ø2 clock oscillator's socket that can generate a low/high pulse sequence when a push button is pressed and released. I will use a DS1813 reset generator to debounce the push button so I get a clean clock transition every time. Since Ø2 is funneled through a flip-flop, each low/high pulse will toggle the flop's Q output, causing the Ø2 clock at the MPU and CPLD to be either low or high. Hence two pushes of the push button will be required to generate one full clock cycle. That will give me the capability of looking at all key logic levels that are being generated in the early stage of reset.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Will be interesting to hear about your single-stepping adventure. If you can run the machine slow enough and investigate enough signals, it surely can't keep too many secrets from you.

Precisely what I am thinking.

As we know, the 65C816 goes through an interrupt-like sequence when RESETB is asserted. By the time the '816 has loaded the start address of the reset handler from $00FFFC-$00FFFD eight clock cycles will have elapsed. So it should be possible to see if the CPLD is doing the correct setups during that time, which would be to map 8K of ROM at $00E000-$00FFFF. I should be able to determine if the ROM is coming in by seeing if its /CS is asserted at the 7th Ø2 low pulse. If so, ROM's /OE should be asserted at the 7th Ø2 high pulse and D0-D7 should have the LSB of the start of the reset handler (conveniently $00).

On the next Ø2 low, ROM should again be selected, and when the clock goes high, I should again see the ROM's /OE asserted and D0-D7 should be %11100000 ($E0), the MSB of the start address of the reset handler. If that is happening I can dismiss a problem with glue logic for the time being and look at other possibilities.

On the other hand, if I see /CS and /OE being asserted when they should be but wrong values on the data bus then I know that while ROM is being selected, its output is coming from the wrong place and my startup code is not where it belongs in the ROM. I can also read the address bus to verify that at cycles 7 and 8, the reset vector address is present on A0-A15. Doing so will be a bit tedious with a logic probe but will help in sorting out the trouble.

To do all this I will burn a ROM whose reset code will consist of NOP followed by STP. These single byte instructions are easy to discern with a logic probe. STP will halt the MPU so it doesn't launch into never-never land if I hit the cycle push button once too often. All other ROM bytes will be $FF, which I should never see on the data bus.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi BDD,

I'd rather would create a minimal CPLD design, one that does not have all the flags, bankswitching and rom overlay but one that just creates the minimal required output signals. It does not even have to support 24-bit addresses. Just ROM, RAM and IOx, RD and WD. And also ignore all input pins which are not really required to run a simple system, no wait states, no interrupts, ignore VPD, VDA, VPA. Because at the moment you need to debug three things at the same time: QUART Driver, Hardware and your first CPLD in a system.

Peter

If the preceding diagnostic path turns out to be a bust I will do just what you described.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!