Lattice ECP5 UART, no signal on terminal emulator

Question

I followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.

1. I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
2. I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
3. Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
4. I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
5. I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
6. I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.

Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.

Answer 1

The following worked for me and it will probably work for others too. I'm assuming you're using openocd.

1. Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:

   00000000  01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10  .....`..Àú....š.
   00000010  AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00  ª<æ.....V.......
   00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000050  00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00  ................
   00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000090  00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00  ............L.a.
   000000A0  74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00  t.t.i.c.e.<.L.a.
   000000B0  74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00  t.t.i.c.e. .E.C.
   000000C0  50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00  P.5. .E.v.a.l.u.
   000000D0  61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00  a.t.i.o.n. .B.o.
   000000E0  61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00  a.r.d...F.T.2.U.
   000000F0  59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27  Y.T.J.V.......ü'
   

   I just post this here for future reference, we're not going to use the stock eeprom.

2. We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:

   00000000  01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10  .....`..Àú....š.
   00000010  AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00  ª<æ.....V.......
   00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000050  00 00 00 00 00 00 02 03 00 00 00 00 00 00 00 00  ................
   00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   00000090  00 00 00 00 00 00 00 00 00 00 10 03 4C 00 61 00  ............L.a.
   000000A0  74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00  t.t.i.c.e.<.L.a.
   000000B0  74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00  t.t.i.c.e. .E.C.
   000000C0  50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00  P.5. .E.v.a.l.u.
   000000D0  61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00  a.t.i.o.n. .B.o.
   000000E0  61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00  a.r.d...F.T.2.U.
   000000F0  59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27  Y.T.J.V.......ü|
   

   Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:

   vendor_id=0x403
   product_id=0x6010
   filename="eeprom_RS232.bin"
   flash_raw=true
   

   With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.

3. Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:

   # this supports ECP5 Evaluation Board
   
   interface ftdi
   ftdi_device_desc "Dual RS232-HS"
   ftdi_vid_pid 0x0403 0x6010
   # channel 1 does not have any functionality
   ftdi_channel 0
   # just TCK TDI TDO TMS, no reset
   ftdi_layout_init 0xfff8 0xfffb
   reset_config none
   
   # default speed
   adapter_khz 5000
   
   # ECP5 device - LFE5UM5G-85F
   jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
   

   Then, create your svf file as you usually do and flash it with the following command:

   sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
   

4. Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.

5. One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.