It begins! (Wren Prototype build log)

[allisonlastname]

Day whatever: got the flash programmer rebuild done! It now fits in a much smaller footprint and has a ZIF socket for ease of use. I might add an external oscillator for the AVR, because at the moment it's running on the internal 1Mhz clock at 9600 baud, which works out to be about half the speed of the old one - still faster than I expected. I expect switching to shift registers over SPI instead of I2C sped it up a bit.

With the flash programmer done, I can now begin the inevitable arduous process of debugging. Wish me luck.

[allisonlastname]

As expected, I turned it on and it didn't work. I've been single-cycling it with an arduino and noticed something odd during the reset sequence: the data bus is always reading 0xFF, even when the flash should be outputting something else. I have no idea what could cause this, but it might be something dumb like the ram driving the data bus when it shouldn't. I can't understand why that would happen, though, because the ram is deselected when A15 is high.

Any help is appreciated.

[BigDumbDinosaur]

allisonlastname wrote:

As expected, I turned it on and it didn't work. I've been single-cycling it with an arduino and noticed something odd during the reset sequence: the data bus is always reading 0xFF, even when the flash should be outputting something else. I have no idea what could cause this, but it might be something dumb like the ram driving the data bus when it shouldn't. I can't understand why that would happen, though, because the ram is deselected when A15 is high.

Any help is appreciated.

I skimmed through the entirely of this topic and didn’t see a schematic anywhere?  Did you post one?  Assisting you would be a bit easier if there is a schematic to review.

[Paganini]

allisonlastname wrote:

As expected, I turned it on and it didn't work. I've been single-cycling it with an arduino and noticed something odd during the reset sequence: the data bus is always reading 0xFF, even when the flash should be outputting something else. I have no idea what could cause this, but it might be something dumb like the ram driving the data bus when it shouldn't. I can't understand why that would happen, though, because the ram is deselected when A15 is high.

Any help is appreciated.

Did you remember to tie BE (Bus Enable) high through a resistor (3.3k is a good value)? I got bit by that one on my first build.

Another possibility, everything is working, but you've got some address lines switched so you're reading from a different part of the flash than you think you are. (Empty flash memory is all 1s, just like with E/EPROMs.)

At one point in my recent project George suggested taking the CPU out of the circuit and driving the address lines directly in order to investigate if the support chips were responding correctly. That was a good idea, and might be useful for you here too.

[allisonlastname]

BigDumbDinosaur wrote:

I skimmed through the entirely of this topic and didn’t see a schematic anywhere?  Did you post one?  Assisting you would be a bit easier if there is a schematic to review.

Here's the current version that I have on the breadboard.

output.pdf

(292.36 KiB) Downloaded 132 times

Paganini wrote:

Did you remember to tie BE (Bus Enable) high through a resistor (3.3k is a good value)? I got bit by that one on my first build.

Another possibility, everything is working, but you've got some address lines switched so you're reading from a different part of the flash than you think you are. (Empty flash memory is all 1s, just like with E/EPROMs.)

At one point in my recent project George suggested taking the CPU out of the circuit and driving the address lines directly in order to investigate if the support chips were responding correctly. That was a good idea, and might be useful for you here too.

BE is tied directly to 5v. I've already double- and triple-checked the flash address lines but I guess it wouldn't hurt to go back through them again. The CPU is pretty hard to access because of how dense the wiring is, but I guess I could pull BE low, hold it in reset, and drive the lines from an arduino.

[BillO]

Why do you have the I/O deselected every time A5 goes high? Or am I reading this wrong?

Actually it says "a85". Where is a85 generated?

Maybe it should read "a8". That would make sense.

[BigDumbDinosaur]

I examined the schematic.  Nothing is jumping out at me.  I’m suspecting a wiring error, faulty boot code or a faulty part.  Are you sure about your chip select logic?

[and3rson]

Just wondering - is there a reason why you're pulling /RST high? DS1813 should work just fine without it.

Also, my tip on /RST: I always wire it through an inverter to a LED (so that it lights up when /RST is asserted). This helped me find many short circuits, since DS1813 will pull the output low if its input voltage drops below some threshold (kind of a brown-out detection).

[BigDumbDinosaur]

and3rson wrote:

Just wondering - is there a reason why you're pulling /RST high? DS1813 should work just fine without it.

The pullup inside the DS1813 is weak.  An external pullup makes the circuit a lot less noise-sensitive.

[allisonlastname]

BillO wrote:

Why do you have the I/O deselected every time A5 goes high? Or am I reading this wrong?

Actually it says "a85". Where is a85 generated?

Maybe it should read "a8". That would make sense.

It's a8 going into pin 5 of the 75hc00. It's more clear on the coloured version of the schematic, but I did it in black and white because I remember someone being colourblind.

and3rson wrote:

Just wondering - is there a reason why you're pulling /RST high? DS1813 should work just fine without it.

Also, my tip on /RST: I always wire it through an inverter to a LED (so that it lights up when /RST is asserted). This helped me find many short circuits, since DS1813 will pull the output low if its input voltage drops below some threshold (kind of a brown-out detection).

In the test setup I'm using, the clock and /RST are driven by an arduino.

BigDumbDinosaur wrote:

I examined the schematic. Nothing is jumping out at me. I’m suspecting a wiring error, faulty boot code or a faulty part. Are you sure about your chip select logic?

I'll go through and check all the address lines again in the morning.

[allisonlastname]

Turns out I'd forgotten that the ROM has a15 tied low, so when the CPU accessed the reset vector it accessed 0x7ffc, not 0xfffc. Yes, I feel pretty stupid.

[BillO]

allisonlastname wrote:

Turns out I'd forgotten that the ROM has a15 tied low, so when the CPU accessed the reset vector it accessed 0x7ffc, not 0xfffc. Yes, I feel pretty stupid.

No need. We all have made "silly" mistakes. The encouraging thing is you found it. Nice work.

[BigDumbDinosaur]

allisonlastname wrote:

Turns out I'd forgotten that the ROM has a15 tied low, so when the CPU accessed the reset vector it accessed 0x7ffc, not 0xfffc. Yes, I feel pretty stupid.

No need to feel stupid.  We’re not designing airplanes or space shuttles here, so no lives are in danger if your machine fails to perform. 

[GARTHWILSON]

BigDumbDinosaur wrote:

allisonlastname wrote:

Turns out I'd forgotten that the ROM has a15 tied low, so when the CPU accessed the reset vector it accessed 0x7ffc, not 0xfffc. Yes, I feel pretty stupid.

No need to feel stupid.  We’re not designing airplanes or space shuttles here, so no lives are in danger if your machine fails to perform. 

I commented decades ago that I wouldn't be able to handle that responsibility, and I'd want a whole string of people checking my work.  I said this to someone who worked in the space program, and he said, "We do have such a chain, and we still get failures!"  I did some consulting a few years ago for satellites; but although it was super expensive to launch them into space and there was no retrieving them for a repair if there was a failure, at least they were unmanned, so no lives were on the line.

[allisonlastname]

IT'S ALIVE!

Pictured is the Wren Prototype running my sanity check program at full 1mhz speed. The program consists of loading from the VIA's port A (inserted for low speed test runs to make sure the VIA was working), then writing 1 to DRRA and port A, followed by an endless loop. As can clearly be seen here, it's working.

The LEDs are (in order, left to right) read/write, a15, /ROM select, /IO select, /VIA select, SYNC, VIA PA0, and a testing LED that I was poking the buses with on single-cycled runs.