gregdavill / ecpprog Goto Github PK

Hi @gregdavill and sorry for taking up so much of your time.

I'd like to extend ecpprog to read/write flash status registers since the ecp5_evn board has a chip (Macronix MX25L12833F) that have QIO disabled by default and I am unsure about how dummy cycles are configured.

• Would you accept such a PR?
• Do you have an idea of a clean API for that? I think the registers name are inconsistent between vendors (i.e. QE is bit 2 of FC_RSR2 (0x35) for Winbond W25Q128JV while it is bit 6 of FC_RSR3 (0x05) for MX25L12833F) so maybe it is better to use opcodes directly.

Also do you know how the ECP5 handles the various flash configurations (e.g. dummy cycles, DIO/QIO) for transparent JTAG programming and for loading bitstream from flash? Does the ECP5 expect a flash chip always in a specific configuration?

Many thanks!

up to the commit 777e5aa, the option to restart the FPGA with the -a parameter worked, after this commit, it does not find the option when executing the command ecpprog

ecpprog: invalid option -- 'a'

This is not an issue but i could not pull a request, sorry.
So is there any chance to program LFE3 devices? Like adding ID codes is enough for that ?
Thanks

'-t' crashes the program running on soft CPU. What I mean is that it touches the flash memory, so the program running on the RISC-V crashes. Worse, it puts the flash in a state so that even when I hit nprogram, the FPGA can not reconfigure itself (done does not go high). So:

1. I think you should have two options: one to just read the FPGA's ID to verify that the connection is working, and another that does that, but also tries to probe the flash memory.

2. Try to figure out why the FPGA can't reconfigure and fix it. Maybe the flash gets into a bad state after ecpprog is done but the RISC-V again tries to read it, I'm not sure.

I've been trying it on the trenz electronic Cruvi Certux-NX board. This comes pre-progammed with the litex bootloader, this is the program that crashes when you use '-t'.

Hi,

Thanks for writing this tool! I would like to move to this tool since it can actually flash the ECP5. For now I use OpenOCD and it only works once after power on. However it correctly identifies the FPGA. But with this tool it finds a device but not with a correct IDCODE.

My openocd config:

adapter speed		10000
adapter driver		ftdi
ftdi_device_desc	"Dual RS232"
ftdi_vid_pid		0x0403 0x6010

transport select 	jtag
ftdi_layout_init 	0x0008 0x001b
ftdi_layout_signal 	nSRST -oe 0x0020 -data 0x0020
ftdi_tdo_sample_edge falling

jtag newtap ecp5 tap -irlen 8 -expected-id 0x41111043
init
scan_chain
svf -tap ecp5.tap -quiet -progress out/design.svf
exit

# this depends on the cable, you are safe with this option
reset_config srst_only

And the output from openocd when it succeeds:

Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : clock speed 10000 kHz
Info : JTAG tap: ecp5.tap tap/device found: 0x41111043 (mfg: 0x021 (Lattice Semi.), part: 0x1111, ver: 0x4)
Warn : gdb services need one or more targets defined
svf processing file: "out/design.svf"

But when I run ecpprog -t I get the following:

init..
IDCODE: 0x0443050a does not match :(
flash ID: 0x00 0x00 0x00
Bye.

I have the following jtag device: https://aliexpress.com/item/1005003513337965.html

If this is the problem I can also get a different one.

I hope this is the correct place to report the issue, I will gladly follow pointers to the appropriate place if it is not.

I am using MacOS X Mojave, 10.14.6.

The ECP5 Versa board, connected over USB, seems to not be recognised by ecpprog when I make use of the FTDI USB serial drivers instead of the native OSX FTDI driver:

$ ecpprog -S full-correlator.bin
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010 or 0x6014).
ABORT.
$ sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
$ sudo kextload -b com.apple.driver.AppleUSBFTDI
$ ecpprog -S full-correlator.bin
init..
IDCODE: 0x02224086 does not match :(
reset..
programming..
Bye.
$

The IDCODE warning message notwithstanding, the bitfile is successfully loaded in the second instance.

While the FTDI USB serial driver is active, the connected board does show up normally in /dev:

crw-rw-rw- 1 root wheel 18, 23 Aug 24 19:30 /dev/cu.usbserial-FT1V75R1A
crw-rw-rw- 1 root wheel 18, 25 Aug 24 19:30 /dev/cu.usbserial-FT1V75R1B

and also appears when I use the lsusb command:

$ lsusb
0403:6010 (bus 20, device 10) path: 1
047d:1020 (bus 20, device 7) path: 2.3
05ac:0221 (bus 20, device 6) path: 2.2
<snip>
$

The top entry in the list above shows the ECP5 Versa board appearing through the expected vendor and product IDs for the FT2232H chip involved (0x0403 and 0x6010). I am therefore not sure why ecpprog does not recognise it.

Happy to provide more information if needed!

There will soon be LiteX support for the Crosslink/Certus NX. enjoy-digital/litex#618

It would be nice to extend ecpprog to support these chips. This shouldn't bee too difficult as the JTAG engine on these parts is quite similar. Additionally the Crosslink-NX Eval board already features an FTDI connection.

Two issues have been identified:

• IDCODEs not present for NX parts
• FLASH verify fails after first sector (4096 bytes)

Hey, I've got a Colorlight 5A-75E board (which has a ECP5 FPGA) and a FTDI232. I've managed to connect all the JTAG pins, however, looks like it cant recognize the board:

❯ ecpprog -t
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010 or 0x6014).
ABORT.

Any idea if this a FTDI problem or ?

lsusb shows:

Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

I've also tried to enable permissions on /dev/ttyUSB0 but no success.

I can provide more info if needed.

When looking at output from ecpprog the byte count during verify sometimes doesn't complete on a the total amount.

$ ecpprog -o 1M firmware.bin 
  init..
  IDCODE: 0x41111043 (LFE5U-25)
  ECP5 Status Register: 0x00200000
  reset..
  flash ID: 0xEF 0x40 0x18 0x00
  file size: 294312
  erase 64kB sector at 0x100000..
  erase 64kB sector at 0x110000..
  erase 64kB sector at 0x120000..
  erase 64kB sector at 0x130000..
  erase 64kB sector at 0x140000..
  programming..  294312/294312
  verify..       262144/294312  VERIFY OK
  Bye.

It would be nice to confirm that the final bytes here are actually being verified, and then display the total count.
Because right now it give the impression that the verify operation completes early, but still return VERIFY OK