Hey, all.

I'm currently working on an project that involves interfacing a 65C816 microprocessor with a Digilent CMOD A7-35T FPGA board (Artix 7). The goal is to leverage the FPGA's capabilities to expand the functionality and performance of the 65C816. I'm doing it in Vivado.

Project Overview:

The 65C816 is running off a 14.31818 MHz oscillator, connected to its PHI2 pin.
Control signals are interfaced with the FPGA through a level shifter.
The project includes memory expansion, UART communication, and custom FPGA logic.

Issue at Hand:
I've hit a snag with the UART communication. When powered up, the UART module continuously sends a stream of garbage characters to the serial terminal on my PC. This issue persists despite various troubleshooting attempts.

Repository:
For a detailed look at the project, including design files and implementation details, please visit the GitHub repository: 65C816 to FPGA Project.
https://github.com/jmstein7/65C816_to_FPGA/tree/main

I'm reaching out for insights or suggestions (or any help whatsoever) on resolving this UART issue (at least, that's what I think it is).

What I've Tried:

Checked and rechecked connections and signal levels.
Validated clock signals and control logic.
Experimented with different UART configurations.

I greatly appreciate any help or guidance you can offer.

Thanks!

Jonathan

By different UART configurations do you mean you've tried other UARTs or do you mean different speeds/stop bits/etc?

Some other things I would do:
Remove the FPGA and try a different UART, such as the 6551 or the 16C550C, (other people have other UARTs they like)
I would also try testing the FPGA without the 65816 controlling it, just tie the address and data pins low and see that it comes up and does nothing as expected.

I see some Verilog on your git hub, but what is the code that you have running on the 65816?
Also, there's no schematic on how you have it connected, that would be helpful to see as well.

Yes. Sorry about that. It's just a basic monitor I wrote. Always reliable. J

Here: https://github.com/jmstein7/65C816_to_FPGA/blob/main/rom_mon.coe

This question would likely do better in the Programmable Logic section as the VHDL/Verilog folks are more likely to notice it there.

Yuri's suggestions should let you determine if it's the FPGA or 65816 that is misbehaving, and the only addition I'd make is to tie the active low lines (like chip selects) high rather than low so that they are "inactive".

You have a state machine in the VHDL for the ACIA_TX. It's of paramount importance to make sure that RESET is activated before you try to use it - not doing so can get you into "unused" states in the state machine and these have undefined action. It looks like you have a button for this purpose. After sending over your bit file, It's important to push the reset button.

When debugging hardware like this, I will add some extra outputs to the PORT and send internal signals out of the module. Then, at the top level of the design, I just map those to unused pins (or pins with LEDs on them, if you're working from a trainer board that has them) and then look at them on a scope. If this was me, I'd be interested in seeing if the ACIA module thinks the TX data register is being written to and I'd be interested in that state machine because the proc_r_txdata process should be in the "stateIdle" state when it's not supposed to be transmitting.

I see a different name and a 2018 date code on the ACIA code, so if you didn't write this, it's also possible you missed something important when hooking it up or using it.

You're right. I'll send Garth a message and see if he'll move it.



Correct. LIV2, another long-time member, wrote it some time ago. I've used it before, in different scenarios, and it can sometimes be the cause of trouble. That's why I jumped to that conclusion [/quote]



I took his advice and ran the memory (.coe) file on another system. No problem there. I'm mystified.

Jonathan

I was referring to this suggestion by Yuri:

That lets you see if your virtual ACIA is always spitting out garbage even when not being used.

When you say "no problem there", does that mean the 65816 works or the ACIA works or both work? If both work, then I would think the most likely issues are mis-wiring, power, or signal integrity. What are the differences between your "No problem there" system and your problem system (including things like connection methods, wire lengths, etc)? If you were running slower (like 1MHz, for example) then you can get away with a lot more "not the best" practices and breadboard-related artifacts than you can at 14MHz.

You also mention you are running the signals through a level shifter. Is that working properly for all signals? This is another item that gets much harder as the clock frequencies increase.

Can you take a photo of your setup?

Here is a pic of the setup. I have a flash chip under the CMOD, but that's not active now - that's for later. Every component has a filtering cap (0.1uF).

What I meant by 'no problem' was that when I upload the .coe binary and burn it to an ordinary EEPROM (55ns), and run it on a regular system I have with a 65C816 and physical components, including a W65C51 ACIA, it works. I.e., the little monitor program works. So, it's not a programming issue.

Edit: I meticulously tested every component, pin by pin. Everything is connected correctly, as set forth in the XDC file.

So testing on your other system has verified that your software should be doing the right thing and that you probably have your pinouts correct.
What we don't know is if the software is actually running.

I see multimeter leads in your photo, so I know you have that. Do you have an oscilloscope? That would be the best tool for looking at the signals and making sure they "look correct".
If your working machine has the same memory map, then you can look at each address, data, and control line on that board and compare to this system, just in terms of what the signals generally look like (eg. high most of the time, alternating rapidly, etc) and will also show if you have signal integrity issues (eg signals not going fully high/low).

You need to break the problem down into little pieces and then devise a simple test that will eliminate possibilities. Here is my understanding of your current position:

It would be good to test a subset of these with the goal of narrowing things down to just #2. We need to assume at least some of this stuff works, but should be open to the possibility that it does not.
If this was my project, because I have had signal integrity issues before, I would likely start by reducing the clock speed. That might make #9 better, but really shouldn't affect anything else. Theoretically, you could go so slow that you could follow along with your multimeter, or even single step. Your FPGA is a very powerful tool as you can add and subtract things from the bus with ease. You can even add a snippet of code that stops the clock at an exact address or bus cycle.

Without an oscilloscope, I would likely write myself an 8-bit latch in the FPGA that just latches when a particular address is written to (can even be an in-use address as this will be a write-only device on the bus). I would then write a small assembly program that does not use any ram (so no JSR - just a single routine) that writes a value to the latch and then you can check it with your multimeter or LEDs+resistors. Put a label at the end and have it jump to itself at that label in order to stop the program while continuing to "run". In that state, only your lowest address bits should be changing and you can check the upper address bits, even with a multimeter, as they shouldn't be changing.

If that works, then you have much more confidence in your FPGA, 65816, emulated ROM, and your connections, and you now have a debugging port that you can write to at various places in your code to see where your program actually runs. This is the hardware equivalent of printf debugging, only you have much more power because you can bring any signals you want to a pin - and even latch them if you want so you can slowly look to see if something happened or not. If this simple test does not work, then you need to focus on the parts that it uses (FPGA, 65816, emulated ROM, connections (even though you think they are all good) and signal integrity (which includes your level shifters).

I am encouraged to see that you're not trying to do this on a breadboard and that your connections are likely short (although I can't see them). To that end, we'd be interested in seeing the back of your board as well. I'm interested to see how your signals and grounds are routed. We'd also love a schematic of where you are right now. It may take some effort to make, if you are working without one, but it will help both you and us determine what you think should be connected to what.

Wow, that's pretty thorough. I'm putting that all together and will upload here when done.

Thanks for such an extensive analysis!

Jonathan

It looks like your FPGA board has two regular LEDs as well as an RGB LED, so those might be what you use for diagnostics. It looks like you already have the two LEDs set up as pins, but they are just following the reset button right now. It might be interesting to put one of them on your acia_enable signal so it lights up when the serial port is accessed. This assumes, of course, that your 65816 is actually running your code from your emulated ROM.

One thing I just tried was using an SN74AC74 to create a sharper edge on the clock. Nope. Didn't work.

The approach I would take to debug this would be to add a "test" bus to the top level design (connected to a small number of unused I/O pins on the CMOD A7 module). I would then use this to expose signals of interest.

I would start by observing phi2, acia_e and tx. Just looking at these signals will narrow down the problem.

Of course, you do need a way to observe these signals, for example a logic analyzer or an oscilloscope. You really do need one or other of these, othewise you are just fumbling around in the dark.

If you have neither, Vivado's Integrated Logic Analyzer (ILA) feature might be worth a try (as a last resort). There is an 8 minute video here which gives an overview:
https://www.youtube.com/watch?v=wf96HMAJo3g

I haven't used this myself, and to be honest if it's anything like the rest of Vivado using it will be very painful. So I think using a real oscilloscope or logic analyzer would be much better.

The other thought I had was that the USB controller on the CMOD A7 is used for both the UART and the JTAG interfaces. Are you sure you are looking at the right port?

As a quick sanity check, you could loop the UART-UART Tx output back to the Rx input in your FPGA and see if you can then echo characters back in a terminal.

Dave

I tried this - checks out.



No need to resort to this



I did verify that the control signals are, indeed going in. I did already measure the frequency coming out of PHI2 with my multimeter, and it's correct.

I just happen to have ordered a new oscilloscope that's arriving today. I'll use that to take the measurements I don't have yet, along with my logic analyzer measurements.

Jonathan

Okay, I ran those signals through my logic analyzer. BTW - now I have nothing from tx?

Curious to know what your thoughts are.

Jonathan

PS As you can see, I have a nice, clean 4mhz signal into PHI2. I slowed it down for the purposes of the analysis.

I see what looks like ACIA_Init being called, although it seems too early to me. Is this the xboot_beta_HW16.asm or xboot_beta_HW16_2.asm file in your repository being used? There are fewer clock cycles than I would expect for either one as they share the same RESET code.

The ACIA_Init signature is the ram_enable spike for two cycles (JSR is pushing return address on the stack) followed by the two acia_enable spikes (ACIA_Control and ACIA_Command being loaded with values) and then another two cycles of ram_enable (RTS is pulling return address off of stack)

The odd part is that I see this same signature later on in your capture when I would be expecting a single acia_enable spike from ECHO who is sending the data followed by a very long Delay. My first through is that perhaps your RAM is not working and you don't come back to the correct place from your first JSR to ACIA_Init, or perhaps your 65816 is getting reset again (although I don't see the reset signature again), but it still could be some other issue.

Later I see an acia_enable access that could be ECHO, but ECHO calls Delay right after sending the byte to the ACIA, and Delay pushes three registers right at the beginning, so I would expect to see ram_enable pulses 3-5 cycles apart and there is only a single pulse near the end of the trace and too many clocks with no ram_enable for it to line up with that code.

If the above asm files (I'm not sure if there is a difference between the two) are not what you are using, please provide the software you are using (otherwise, I'm wasting time fumbling around in the dark). You may even want to create a "minimal example" that doesn't have all of the SWEET16 junk in it - just init the ACIA and send a character over and over (or even just once). The fewer instructions/clocks to get to the problem, the better.

There should be a "signature" of actions at various clock cycles for each assembly instruction, and I'm not seeing things line up nicely between the code and your hardware. It could still be a signal integrity problem, such as an issue with your level shifters, and the scope will help see those kinds of issues.

I see enough to have a little more faith in your emulated ROM and your 65816 (eg. your processor is trying to run code), but I'm not convinced your RAM is working properly and it could be an issue with your level shifting. I also don't see your code setting up the stack pointer, but I'm not sure if that's important or not.

I'd love to see you cut your assembly down so small that the running will entirely fit in your trace.