trabucayre changed the topic of #openFPGALoader to: Universal utility for programming FPGA / Github: https://github.com/trabucayre/openFPGALoader/ Logs: https://libera.irclog.whitequark.org/openFPGALoader
<ysionneau> hello!
<ysionneau> I am trying to program the ECP5 fpga board I've designed
<ysionneau> I get this error :
<ysionneau> mismatch between target's idcode and bitstream idcode
<ysionneau> bitstream has 0x21111043 hardware requires 0x00000000
<ysionneau> the --detect works fine ,it detects the FPGA idcode
<ysionneau> here is the entire log with my cmdline : https://pastebin.com/RxvxcSZz
<ysionneau> I am guessing the issue is my cmdline :)
<ysionneau> bitstream contains correct idcode .. and openFPGAloader detects correct (and same!) idCode on the jtag chain ... but still somehow it's not happy ^^
<ysionneau> I've tried with openFPGALoader v0.12.0 and v0.13.1
<trabucayre> which cable you uses?
<ysionneau> -c ft232 (real cable is ftdi C232HM-DDHSL-0)
<ysionneau> I have not plugged the VCC red wire but I guess it's ok, since the board is already powered-on from some other source
<trabucayre> Weird: look like something is wrong with idCode instruction
<trabucayre> looks like tdi is noisy
<trabucayre> if the device is detected this mean TCK/TMS looks fine
<ysionneau> maybe I can reduce the clock or something
<trabucayre> comparison is done between idcode read from the bitstream and idcode received after IR/DR transaction
<trabucayre> could you try without --index-chain and --fpga-part
<trabucayre> but yes maybe reducing rate
<trabucayre> have you another cable to test? (digilent_hs2 or something like that)
<ysionneau> with just -v -c ft232 top.bit it's the same issue
<ysionneau> hmm no other cable I'm afraid
<ysionneau> isn't it weird that --detect works?
<ysionneau> isn't it using the same wires ?
<trabucayre> detect is just a sequence of 0xff
<trabucayre> FPGA is moved to TEST LOGIC RESET state -> SHIFT_DR followed by a long sequence of 0xff
<ysionneau> ah so there are 2 ways of getting the idCode
<trabucayre> yes
<trabucayre> one generic (this one)
<trabucayre> and another device specific
<ysionneau> arg ok
<ysionneau> let's use the scope to find out if TDI is that noisy
<ysionneau> ahah fun, if I put a scope probe on TDI => it works
<ysionneau> what I see on the scope if quite clean
<trabucayre> If it's works there is something wrong here...
<ysionneau> well not completely sure here
<ysionneau> does it look like working to you trabucayre ? https://pastebin.com/2SKH4D2Q
<trabucayre> Not stable...
<ysionneau> what makes you say this from the output?
<trabucayre> I'm confident about lattice code because I have used it this week to test some PoC on new cable driver
<trabucayre> BSE Error Code
<trabucayre> Looks some data/bits corruptions
<trabucayre> unfortunately I haven't this cable to check is everything is fine with this cable
<trabucayre> But usually when a cable works sometime, or with a external help (oscilloscope/LA) it's usually an issue with pull resistors or poor contact
<ysionneau> lemme check if I forgot the pull up
<ysionneau> I've put a pull up on TDI towards 3.3V
<ysionneau> my bom says 4k7
<ysionneau> maybe the assembled one is wrong
<ysionneau> multimeter says between 4.43 k and 4.6k
<ysionneau> trabucayre: which cable do you recommend ?
<trabucayre> one I uses the most is the digilent_hs2
<trabucayre> maybe Maximum output of 250mA is not enough ?
<ysionneau> hmm if you're quoting the ft232 cable datasheet
<ysionneau> I think it's about the Vcc wire
<ysionneau> which I didn't plug
<ysionneau> I could try to plug it
<trabucayre> no
<trabucayre> vcc from your board is usually to feed FTDI VIO
<trabucayre> gnd is enough
<trabucayre> but in datasheet it's Io is 250mA
<trabucayre> Maybe I have to get one to see
<ysionneau> ah yes right
<trabucayre> do you have a simple ftdi break board?
<ysionneau> nop :/
<trabucayre> a cable not based on ftdi?
<trabucayre> USB Blaster?
<trabucayre> rpi2040 with dirtyJTAG?
<trabucayre> (it's just to test with a different cable)
<ysionneau> not sure I have another cable
<ysionneau> but I'll check
<trabucayre> 'k
<trabucayre> sorry I have to move a bit...
<ysionneau> maybe some digilent cable since Ihave some digilent boards
<ysionneau> thanks a lot for your help!
<ysionneau> talk to you later :)
<trabucayre> maybe yes
<trabucayre> any cable support by openFPGALoader will be ok
<trabucayre> an FT232RL too (but it's really slow)
<trabucayre> or an raspberryPI with libgpiod (it's really really slow too)
<ysionneau> I have an TTL-232R-3V3 cable
<cr1901> I don't imagine it's the same error, but I've had fun errors like this before: https://github.com/trabucayre/openFPGALoader/issues/230#issuecomment-1186267033
<ysionneau> according to doc, the cable uses FT232RQ IC
<ysionneau> what would be the pinout to use for the TTL-232R-3V3 cable (if it's supported :o)
<ysionneau> ah it's explained in the doc
<ysionneau> it seems it would be --pins=0:1:2:3
<ysionneau> but still no luck