IDCODE doesn't match openocd and also doesn't match any part
rowanG077 opened this issue · 4 comments
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.
Can you try slowing the clock down? It might be you're seeing SI issues over the wires?
ecpprog -k 10 -t
It didn't change anything. Even going as slow as 30. But I bought the adafruit FT232H breakout board(https://www.adafruit.com/product/2264) and connected the wires because I think my other jtag thingy is counterfeit. This time it does detect the FPGA correctly:
init..
IDCODE: 0x41111043 (LFE5U-25)
ECP5 Status Register: 0x00600100
flash ID: 0xEF 0x40 0x16
Bye.
But when I try to program it it fails the verification:
$ sudo ecpprog out/design.bit
init..
IDCODE: 0x41111043 (LFE5U-25)
ECP5 Status Register: 0x00600000
reset..
flash ID: 0xEF 0x40 0x16
file size: 584687
erase 64kB sector at 0x000000..
erase 64kB sector at 0x010000..
erase 64kB sector at 0x020000..
erase 64kB sector at 0x030000..
erase 64kB sector at 0x040000..
erase 64kB sector at 0x050000..
erase 64kB sector at 0x060000..
erase 64kB sector at 0x070000..
erase 64kB sector at 0x080000..
programming.. 584687/584687
verify.. 4096/584687Found difference between flash and file!
ABORT.
The design.bit is generated by ecppack. Interestingly the k option doesn't change the time to program that significantly. At default it takes 27 seconds. At k = 30 it takes 32 seconds and at k = 60 it takes 37 seconds.
When I try to write some random data into flash and read it back it shows that it only reads 0xFF:
$ dd if=/dev/urandom of=./rand_data_in bs=256 count=1
1+0 records in
1+0 records out
256 bytes copied, 8.8249e-05 s, 3.9 MB/s
$ sudo ecpprog -X ./rand_data_in
init..
IDCODE: 0x41111043 (LFE5U-25)
ECP5 Status Register: 0x00600000
reset..
flash ID: 0xEF 0x40 0x16
file size: 256
erase 64kB sector at 0x000000..
programming.. 0256/0256
Bye.
$ sudo ecpprog -R 256 rand_data_out
init..
IDCODE: 0x41111043 (LFE5U-25)
ECP5 Status Register: 0x00600000
reset..
flash ID: 0xEF 0x40 0x16
reading.. 4096/0256
Bye.
$ cmp -l rand_data_in rand_data_out | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
00000001 B6 FF
00000002 08 FF
00000003 51 FF
00000004 BB FF
00000005 28 FF
...
...
000000FD 69 FF
000000FE 7A FF
000000FF 65 FF
00000100 6E FF
$
So I now thought I have wrong wiring but this doesn't seem to be the case. Below I have the wiring setup and two pictures.
- RED: 3.3V <-> 3.3V
- BLACK: GND <-> GND
- ORANGE: TCK <-> D0 (Which according to adafruit is ADBUS0)
- YELLOW: TMS <-> D3 (Which according to adafruit is ADBUS3)
- GREEN: TDI <-> D1 (Which according to adafruit is ADBUS1)
- BLUE: TDO <-> D2 (Which according to adafruit is ADBUS2)
Wow I just added the -p option to disable flash protection and it works! I feel stupid now haha. I will leave the comment for anyone who stumbles upon this issue.
Ahh nice that you worked it out. Yes, on the colourlight board the FLASH has write protection enabled by default.