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
<trabucayre> An external library? I have no problem with rust :)
<trabucayre> But I don't know how to access a rust libary from cpp code
steve|m has joined #openFPGALoader
<steve|m> it seems that I've managed to brick my Tang nano 4K with openfpgaloader :(
<trabucayre> steve|m: could you provides more informations?
<steve|m> everything was working fine until I wanted to program the bitfile to the integrated flash using the -f option
<steve|m> now the board is detected with the wrong IDCODE
<steve|m> JTAG init failed with: Unknown device with IDCODE: 0x0100881b (manufacturer: 0x40d (Gowin), part: 0x08 vers: 0x0
<steve|m> same for the official gowin programmer
<trabucayre> weird. This information isn't stored into flash
<steve|m> I patched openfpgaloader to that 'new' idcode, and for example loading sram works from the output of the loader, but the fpga itself doesn't, not even a blinky
<trabucayre> if your bitstream has the real idcode it will not be accepted
<trabucayre> but it's the first time I see IDCODE changes
<trabucayre> d
<steve|m> the bitfile I initially programmed doesn't use any of the dual-purpose pins, but I also tried pulling MODE high and JTAGSEL low, no change, always 0x0100881b
<steve|m> also tried with lower clock etc.
<steve|m> at this point I'm quite puzzled
<steve|m> just one bit difference, 8 instead of 9
<trabucayre> It look like the hardcoded IDCODE was reprogrammed
<trabucayre> And of course this type of informations aren't present into gowin's datasheet...
<steve|m> my next thought would be patching the original programming tool to this idcode and try program/erase with that, but that is a big chunk of compiled python garbage
<steve|m> a couple of weeks ago I successfully programmed the internal flash with the gowin programmer
<steve|m> but since then only used SRAM loading with openfpgaloader
<steve|m> also now with the patched idcode, if I try to write the flash:
<steve|m> CRC check : FAIL
<steve|m> Read: 0x00000000 checksum: 0x0856
<trabucayre> I don't remember but idcode is maybe integrated to the formula to computre CRC
<trabucayre> when you have tried to flash have you seen error related to libftdi or libusb ?
<trabucayre> usb interface is sometime a bit unstable, and it's depends on your env, cable, usb hub, etc.
<steve|m> no, everything went fine, I was very surprised when I replugged the board and it was not detected anymore
<trabucayre> nothing in dmesg?
<trabucayre> with openFPGALoader's master branch?
<steve|m> nothing in dmesg
<steve|m> no, 0.11.0 from AUR
<steve|m> now for the patched IDCODE experiments I'm using master though..
<steve|m> huh, what is interesting is that writing/verifying the external flash works
<trabucayre> external yes, but you can't boot from external flash :-(
<steve|m> shouldn't that be possible by pulling MODE high?
<steve|m> it doesn't work here anymore, though..
<steve|m> well.. that thing is pretty much bricked.. luckily a tang nano 9K should arrive in the next days
<trabucayre> too bad :-/
<trabucayre> I have seen a couple of gw1n bricked but never with a wrong IDCODE
<trabucayre> bricked for flash access but working for sram
<steve|m> I have to take a look at the DONE pin
<steve|m> done does a short pulse to high and then is low again
CarlFK1 has joined #openFPGALoader
CarlFK1 has quit [Ping timeout: 255 seconds]
CarlFK1 has joined #openFPGALoader
CarlFK1 has quit [Ping timeout: 264 seconds]