I have been trying to implement a UART in order to communicate between my Lattice MachXO3D board and my computer. At the moment I am attempting to implement the transmission from the FPGA.

Upon testing on the hardware, I encountered a very strange issue. If run normally, it will function for a few seconds and then it will suddenly stop functioning (The CH340 connected to my computer will report it is receiving messages containing 0x0). However, if I embed a logic analyzer onto the FPGA through the Lattice Diamond software, and I run the analyzer, it will function perfectly for an extended period of time.

Sadly, I don't have a logic analyzer, so the embedded logic analyzer is my only chance at knowing what is actually being transmitted.

These are the files related to my implementation:

Baud Generator (Generates 16 ticks per bit)

Transmitter

Test bench

Hi. Without going into the review of your source code..

The Uart ip is directly linked to the clock source for the respective framing. What is the clock value being used inside your lattice FPGA? 

Are you selecting 24mhz? Or is this clock value being applied externally? Accuracy of the master clock is critical to the accurate generation of the baud rates.

This is very important else the ch340 usb uart bridge will not frame the data properly.

Consider to spew out a fixed ascii character such '1' = 0x31 in a permanent loop. Then use your setup with tera term or similar and keep tweaking till you frame this packet properly.

See here:

https://www.fpga4fun.com/SerialInterface.html

Hi mon, thank you for the reply.

I'm using an external 12mhz crystal oscillator, which was included on the board. I then connect this to an internal PLL in order to generate 24 mhz. Unless the PLL is adding inaccuracy this clock signal should be quite accurate.

Reading a sample message coming from the CH340 using the FPGA's embedded logic analyzer(using the 24mhz clock for sampling) confirms this, showing that each pulse is pretty much always the same width.

At the moment I am testing as you say, sending the fixed ascii character 'a' from the FPGA constantly. The problem is that after about five seconds, the CH340 reports only receiving '0x0'. If it was an alignment issue, it should report to be receiving some other character. But it almost looks like the FPGA really starts transmitting 0x0 after a while.

What is weirdest is that when I am listening with the embedded logic analyzer, it will work perfectly, and continue to transmit 'a' continuously. That is why I am at a loss and unsure what could be causing the issue.

Review that your ch340 drivers are up to date.

Be sure that hardware flow control is OFF on the ch340. You can simply short rts & cts pins together or note the same on your terminal program.

Assuming that all of this interconnect is at cmos levels and not rs232 levels otherwise you do require a rs232 transceiver.

Try the same test @ 9600 bps on your fpga and also the ch340.

Another suggestion is to consider 9600 bps and dial up your baud rate generator to operate from your native 12 MHz and even 8 samples per bit which is fine for such slow baud rates. Only to remove the pll out of the equation.

I'm running linux 5.8, and I checked the modifications that have been done to the driver in version 5.9. They all seem to relate to break emulation, which I imagine I don't used.

I've both checked in my terminal program that the hardware flow control is off, and shorted the pins together.

The interconnect is indeed at cmos levels, with a voltage range of 0-3.3v.

I tried setting running it at a baud rate of 9600, but I get the same issue. It sends the character 'a' successfully for a few seconds and then it fails. However, if I listen on the logic analyzer that I embedded, it works just fine and does not fail.

I tried it with another implementation of a UART I found online and it results in the same issue. Thus I am starting to think the design is also correct.

If it was an issue with the driver, then why would it work when I am listening on the logic analyzer?

What could be happening here? Could it be an issue with the FPGA itself or a bug in the programming software?

Perhaps it was not a good idea to get a Lattice FPGA to learn with?

Lattice is a fine FPGA to learn from. We have done the same. Their tools for the most part are affordable and the hardware works, the documentation sucks and is full or errors and their is little to no support from the factory. Lately their offshore support team has been pretty good but over worked. Simple questions can take a week or more to answer from the support group. I suppose it is better than not receiving any tech support. Altera was pretty decent when we did some early review of using their devices due to low cost (fpga4fun has some SRAM based Altera kits) - that website is amazing to learn from as we have done. Now that Intel has taken over, good luck with any support. Their approach is buy volume or get out of the way and pay their asking price.

You may want to also review the use of Gowin (China) who is starting to make some impact in NA and also Efinix.

We have invested the last 6+ months to refine our 8 pin DIP version of the Dipsy board (we call it ICEPIK) which is based on the ICE40UL1K Lattice FPGA.

On your project, stream out 5 bytes of your 'a' -> then pause a few seconds -> repeat. Does that work for you?

Perhaps the CH340 is being overrun with the data - the UART is a common factor in your setup. I know that CH340 has many iterations to the device but personally use the FTDI device. The FTDI controller is $$ but is rock solid on hardware and software drivers.

Which MACHXO3D board are your using? Can you share a link? I think we may have it here in the lab as well. I think I may have a CH340 USB bridge here as well - 100% have the FTDI cables here.

From reading your post, I think you are doing quite well in learning about FPGA. Openly, have not jumped into the simulations, etc. of the Lattice toolchain. Did not learn this back in university days and with limited time, internet is our teacher. Don't give up - the Lattice devices are quite nice to use.

Update:

I do not believe we have the same kit in the lab but review the hardware manual for the kit. There is a schematic at the end of the document.

See attached on the possible use of the 2nd port on the FTDI chip that is onboard your kit. That is, if you apply the short for the RX of the UART, your FPGA should be able to TX to the outside world - so we can remove the CH340 out of the equation. Openly do not have much faith with the CH340 device - it sells for < $ 0.50 USD in China in single qty.

Change your UART port pin assignment to use the 'SDA' port pin on the FPGA and apply the short. If I understand correctly, what you transmit should be received by the COMx (2nd port) on the FTDI controller.

Curious to hear your status.lattice1.jpglattice2.jpg

I will try sending 5 bytes in intervals, and I'll let you know if that behaves any differently.

I did notice that connection in the board schematic before I decided to use the CH340. However, for some reason when I connect the board, dmesg generates the following messages:

[34142.491688] usb 1-13.2: FTDI USB Serial Device converter now attached to ttyUSB0
[34142.495790] usb 1-13.2: FTDI USB Serial Device converter now attached to ttyUSB1
[34143.147267] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[34143.148027] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0

As you can see, the tty is disconnected as soon as the USB is connected. I thought it was due to the ROM configuration for the FTDI chip, but it could also be the drivers. I've tried looking up the issue online but so far have found nothing useful.

Thank you very much for your help, you've been incredibly helpful.

Hi. I believe in karma. When I was 13/14, had the amazing support of local school teachers and University profs to encourage myself into the field of digital logic. That along with a great sales / tech guy at the local Radio Shack. He would invest time during his lunch hour to correct any misunderstanding I had about Popular Electronics magazine schematics. That was many moons ago. Fast forward 35+ years, own a tech company and now have 1M+ adapters of serial ports in the industry and 1200+ designs to date. We have alpha & beta tested for the largest UART companies in the industry and are suppliers to most of the tier 1 OEM firms. So for this and other reasons, trying to give back where little I can. While you are not quite working yet, you are on the right track. As noted, we are relatively new to the use of Verilog and FPGA devices but finally it is starting to make sense to us as we continue our custom PCB designs using the ICE40UL1K and soon, other Lattice devices. Wish to become like the Adafruit for some higher tech designs at affordable costs. The ICEPIK FPGA board we expect to sell @ < $10 USD in single qty. It has taken months of R&D to get this design to be production friendly and advanced SMT equipment to build.

The FT2232H is a dual port USB bridge with MPSSE engines for each port. That is, they can be morphed to assorted permutations of interfaces. We are about to start purchasing their FT232H in volume as the controller is PnP supported on the Lattice Diamond and any other toolchain you can find which is gold for us once we release our product into the industry.

Cameron (FTDI USA is a great support FAE at their factory) - he recently shared the following programming tool which will index their controller -> reflash the 93C56 EEPROM to take on the personality you choose:

https://www.ftdichip.com/Support/Utilities/FT_Prog_v3.10.132.511%20Installer.exe

So it may be as you stated, the EEPROM is configuring your FTDI port # 2 to be something else and you will require this tool to reflash to becoming a normal UART. Give it a run if you can on Windows and your Lattice kit.

Linux is not always refined so does not hurt to test on Windows on your observations.

Good luck! Do report back your findings. While frustrating, it is great when it starts to work.

Your story is very inspiring, I hope one day I can achieve something similar. I'm a second year student of computer science. However, I started learning about Digital Logic in my senior year at High School, after having programmed a few games for the Commodore 64 (I got interested in retro computers). At that time I decided to build a 6502 computer, which took 3 months but I did complete. However, once it was built there was not much logical circuit design to do, so I quickly became disinterested.

However, recently I had a course about digital circuits where they taught us the very basics of VHDL. I became fascinated and used the book "Circuit Design with VHDL" by Volnei A. Pedroni. I've decided after I implement the UART, I will implement a VGA controller and finally a processor architecture that can run CHIP-8 opcodes.

Back to the project at hand, I tested the board on Windows and ran the utility you sent. Indeed, both channels are already set to rs232 mode, so no changes need to be made. I checked if there were any COM ports and they were in fact there, two of them. I tried sending data to the second one, and confirmed with a logic probe that data was being received at those DNI resistor pads.

I shorted those resistor pads with a small wire. I had some problems with shorts because of the solder making small connections between neighbouring pads. Very hard to see those small components, I should get a magnifying glass for this.

It turned out the reason my Linux machine was not showing the tty's was because I had disabled the drivers, since Lattice Diamond uses it's own drivers for its programmer. I solved that by using an open source programmer instead, openFPGALoader.

They didn't support my FPGA out of the box but since it's open source adding support was very easy. My modification to allow this has now been merged to their main repository.

Finally, I was able to test using the FT2232 and the result was:

It works! Now I can receive data from the FPGA without any interruption. I am not sure why there were problems with the CH340, but it's good I don't need a dongle hanging off the board any more.

I can now move on to testing the receiver and next designing a VGA controller. Thank you very much for your help! 

What you have is what the engineering profession calls a Heisenbug. That's a bug in hardware or software that changes as soon as you use a tool to try to observe it.

The easiest way to deal with a Heisenbug is to probe it with something as non-invasive as possible. For something like an FPGA that would be an oscilloscope. Serial port data rates are fairly low, so if you could beg, borrow or steal a simple oscilloscope of some sort that would really help narrow down whether the issue is on the FPGA or PC side. Even a simple voltmeter should be able to tell you whether or not the FPGA suddenly starts sending 0x00 after a few seconds versus something like the character '?' (0x3F).

If not, then you have to ask yourself what changes on the FPGA side when you compile in the logic analyzer with the rest of the code. Is a required FPGA global variable or configuration being set by the logic analyzer code that isn't in your code? I'd look for issues like that first.