Good morning, guys!



Nothing fancy at all. I was actually just looking to get a new logic probe, as the end of my "good" probe got wrecked (i.e., my kids probably played with it). So, instead, I just decided to get one of the little, simple, basic handheld scopes that Amazon seems to push on me - a ZeeWii KSO136Pro. For just a few signals here and there, it seems to fit the bill.



Yup, yup. Then that's what I shall try.

Thanks! To be continued!

If the scope turns out to be useful, I'll probably invest in a "serious" one.

Jonathan

While the single channel will limit what you can measure (you need two channels for propagation delay type measurements) and triggering will be more difficult (it's common to use one channel to trigger while looking at signals on the other channel(s)), this should still be a good diagnostic tool. While I'm able to locate the item on an sale at Amazon -- I especially enjoy the photoshopped photo with the probe (sans ground clip) in one hand and solder in the other -- I don't see the manual for it available anywhere so you will have to refer to the manual that came with it.

With the limited bandwidth of your scope, I'll recommend you run your setup at 1MHz.

Quick Scope Usage:
The yellow arrow on your left side of the screen is the GND location (because you can move the entire signal up and down on the screen, so you need to know where "0V" is). Your signals should either be near this level or they should be near 3.3V or 5V higher (depending on which side of your level shifters you are on). Wiggles are allowed as long as they are not too big (eg. you should stay within the upper or lower 1/3 of the voltage range for the logic).

The yellow arrow on the right is your trigger level. The scope will draw when it sees the signal cross this level. You can choose rising edge or falling edge (shown in the upper right).
If you are in NORMAL mode (shown in the upper right), then the screen will only redraw when the signal crosses the trigger point in the correct direction, which make it look like the scope is "stuck" if the signal never crosses that level. When set to AUTO, the signal will wait a short while for the signal to cross the trigger level, but it it doesn't, it will just go ahead and redraw the trace anyways. You want Auto for looking at things that don't change (like power rails), but Normal will do better for a signal that changes a lot when you want to see a steady signal (assuming the signal repeats).
The arrow at the top of the screen shows the exact point where the scope triggered. Because this is a digital scope, it has data before and after triggering.

At the bottom of the screen are your vertical scale (in Volts or mV) and horizontal scale (in seconds/ms/us/ns). The scope can't tell if your probe is set to 1X or 10X, so make sure the setting on the screen matches your probe. You will always want to use 10X unless you know what you are doing. With that set properly, the value given here is for each division of the large grid. Many scopes uses dotted lines, which divide that into 5 or 10 sections. I'm guessing yours is 5 little divisions on the dotted line. As an example, if the vertical scale is 1V/division, then each large box is 1V high and the little dots in the dotted lines are 200mV each. This lets you measure voltages. It's recommended to move the GND reference for your signal (arrow at left of screen, and it moved the entire signal up and down on the screen) so it points directly to a grid line to make the grid easier to use for measurements.

The time scale works similarly, but for time.

Your scope has an AC/DC selector switch at the top. You will want DC most of the time, but the AC mode can be useful for looking at wiggles - an example would be looking at the power rails for your circuit, when you want to block the 3.3V or 5V from going into the scope and only look at how these signals wiggle. Because the DC component has been removed, the signal shown will display as above and below 0V - in reality it's above and below your average DC value.

A good scope shot will use more than 50% of the vertical size of the screen without any signal off the screen vertically. If the signal changes in a repeated pattern, it should have 2-3 cycles of the pattern on the screen, unless you are trying to zoom in to a particular section. If it's a non-repeating signal, use the RUN/STOP button to repeatedly take "snapshots" until you find one with both a high to low and low to high transition in it. If taking a photo of the screen, make sure the entire screen, including the info around the edge of the screen, is in the photo - this let others know how it was triggered and how big it is in voltage/time.

http://www.zeeweii.com/download/ZEEWEII-dso154pro_UserGuide_En.pdf

Sorry. Here it is.

J

Okay, here's what I have:

These are 3 signals: 8mhz clock, on the B (5v) and A (3.3v) sides of the level shifter, as well as a data line, and address line, and the RWB signal, all on the B and A sides of the shifter. If you open the images or zoom in, you will see that I have labeled each item with text at the top of their respective screens.

What do you make of it?

Jonathan

The RnW signal is interesting... low of 375us (3 cycles) high for 500us (4 cycles).

Is this pattern repeating forever?

Most likely this is executing an infinite series of BRK instructions.

Dave

Yup, repeating ad infinitum.. Can you see any artifacts or effects from the level shifter? How can I use this data to fix the project, if at all?

Thanks!

Jonathan

Everything there actually looks pretty good, voltage wise. It looks like your clock might not be 50% duty cycle (the high and low parts should be equal), but I think we're also running into the limits of your bandwidth on the scope, so it's difficult to tell for certain. If you can reduce the clock to 1MHz (or less), we should be able to get a better picture there. That's probably not your issue, though.

You will want to verify that each line goes both high and low at reasonable levels, similar to these that you've shared with us. This sometimes requires writing and running special programs that exercise the hardware a certain way so the scope can look for a particular signal. For the address lines, that might mean writing a program that reads from $0000 and then $FFFF (perhaps using LDA instructions) in a loop. The address lines will have those addresses (as well as the addresses to run that bit of code) on them over and over, so you will see both highs and lows on every address line. Without the test program, you might have the upper address lines never change at all if the code is all running in the $C000-$FFFF range.

You might then change the software to load A with $00 and then write it into a RAM location, then load it with $FF and write it to the same RAM location. This will have both reads and writes occurring on the databus (there will also be the bytes to for those assembly instructions, as the CPU pulls the code from ROM one instruction at a time to run it). You can look at each data line to make sure they all go fully high and low. Note that the databus usually flats at times, and can have "in-the-middle" voltages on it during those times, but I believe your level shifters have devices that hold the bus at the last value until it is driven the other way, so you probably won't see that on this setup.

You should also probe all the control lines, like RESB (which should just be high near 5V when your program is running). You are looking for any voltages that are "in the middle" of the voltage range. The slight excursions below ground and over the supply voltage aren't exciting unless they are large (and some of them may not be real and are a byproduct of using the alligator ground lead on the probe). The dips on the clock line, for example, are the size I would normally be concerned by (over 1V on the 5V side!), but I'm guessing the ground you used is a ways away from the oscillator's ground. If you move the scope's ground connection to the oscillator's ground, I expect that dip below 0V will be much smaller. Fast moving signals, like clocks, are more likely to exhibit this effect.

Also check your power rails (and your GND connections at each IC). They should be pretty steady, but will have ripples just like you see in your signals. When looking at the power for a particular IC, you should use the IC's GND pin as your ground reference (rather than just clipping on whatever is convenient to clip on), because the GNDs are not all the same and it's the "local" ground that is important for an IC.

If you go around your circuit and all of your logic looks like logic (eg. either high close to the supply voltage or low near ground), then that will greatly reduce the likelihood of your issue being signal integrity issues. Your level shifters appear to be working well in the scope shots you have provided, so I'm less concerned about those at this point.

If you aren't sure how to write the suggested test software, let us know and we can help you out.

That was my thought as well, meaning the 65816 is getting $00 over and over on the data bus. The ROM has large sections of zeroes in it, so it might be running in the middle of one of those blank sections during that capture. I'm not sure if it's a hardware, software, or FPGA issue, though. That's why I recommended a minimal test program that does not use RAM at all. We're making some progress on the hardware front of things with the scope, even if it's just determining which things probably aren't the issue.

All this indicates is the CPU ends up in a state where it seems to be continuously executing BRK instructions. Even this is a hypothesis, as other type of exceptions can look like this.

It doesn't explain why.

You really need to take a step back and slow down a bit...

You haven't posted any schematics, nor a complete assembly listing of the ROM. Without this background, it's hard to make constructive suggestions.

Are the ABORTB, IRQB and NMIB inputs are all pulled high? A schematic would answer this.

What exception handling does the monitor ROM have?

Is the github repository up-to-date with your current VHDL source code?

Yesterday I tried to build the project, but found:
- the .xpr file was missing, so I needed to create a new project from scratch
- the rom_mon.coe file was in the root of the project, but the ROM IP was looking for it at imports/test_bench.srcs/rom_mon.coe

I gave up at that point.

You still need to look carefully at the Vivado warnings, to see if there any further clues. If for some reason the Monitor ROM data wasn't being loaded into the ROM by Vivado, then you would likely end up with the CPU executing BRK instructions (opcode 0x00) forever.

Also, consider SamCo's suggestion to create a mininal test ROM that just writes something to the UART without needing RAM to be working.

Personally I would switch back to the logic analyzer, and try to observe what the 65816 does immediately after reset. Trigger off the rising edge of reset, and look at Clock, Reset, RnW, VPA, VDA and VPB. From those, there should be evidence that it's executing the expected reset code, or alternatively that it's immediately crashing.

If you can get hold of a logic analyzer with 16 inputs (such as one of the cheap Cypress CY7C68013A FX2LP development boards), software exists that can decode the instructions that the 65816 executing. See this thread on startdot. This will work with any logic analyzer that can sample 16 bits.

Dave

Oh, that’s a cool forum. Thanks! I’m an American, but I’m obsessed with the Beeb. Ever since I saw micromen, watched some Chris Curry interviews, and learned about the Tube. Much cooler than anything the Apple ][ ever did!

Jonathan

For me, a minimal ROM would be one which directs all three vectors straight to a jump-to-self. You need to have the very minimum going on. Especially as you now have a scope and as you want to know if the machine is even getting anywhere at reset. (Three distinct jump-to-self instructions might be a good plan. Place them at addresses which makes it easy to see which address you've landed at.)

I'll post some schematics. It's pretty straightforward.

Regarding the rom_mon.coe, I just open the distributed memory IP that accesses the ROM and reload it into the Distributed Memory Generator.

The only Vivado warnings I got had to do with domain crossings, so I started reducing the number of clocks last night and employing clock dividers.

As you said, I'll take a step back and get all this up here after work, maybe sooner.

Regarding the signals like IRQB and NMIB, etc., I have those pulled high with 1K resistors on the 5v side of things. They're connected to the FPGA so they can be pulled to ground by the HDL.

Jonathan