Closed machdyne closed 1 year ago
Sorry about this. I believe -7 means a timeout on the USB read. Can you try this command: sudo openFPGALoader -c dirtyJtag -detect ? If this does not work, please check the wires going across the 2 boards. Failing this, you will have to debug the pico program or watch the signals with a logic analyzer. Good luck!
Thanks for the response.
I get a similar result with that command, the ID code seems to be random.
I am now using a Pico as the programmer, have tried two different ECP5 target boards and different wires.
$ sudo openFPGALoader --cable dirtyJtag --detect
getVersion: read: usb bulk read failed -7
Jtag frequency : requested 6000000Hz -> real 6000000Hz
writeTDI: read: usb bulk read failed -7
JTAG init failed with: Unknown device with IDCODE: 0x0d422991 (manufacturer: 0x4c8 (), part: 0x6a vers: 0x0
When using a usb-blaster cable:
sudo openFPGALoader --cable usb-blaster --detect
index 0:
idcode 0x1112043
manufacturer lattice
family ECP5
model LFE5UM-45
irlength 8
I am not sure what to say at this point. The fact that you get a timeout error in getVersion is rather strange. Can you try the same command without any cables attached to the pico board? You should get this: $ ./openFPGALoader.exe -c dirtyJtag --detect Jtag frequency : requested 6000000Hz -> real 6000000Hz If you get a timeout again, then I suggest you try to debug the pico board... It is possible that your custom board isn't compatible with the official Raspberry Pico board and that some tweaks are necessary in the CMAKE file of the project.
This is using an official Pico board with no cables attached:
$ sudo openFPGALoader -c dirtyJtag --detect
getVersion: read: usb bulk read failed -7
Jtag frequency : requested 6000000Hz -> real 6000000Hz
writeTDI: read: usb bulk read failed -7
JTAG init failed with: Unknown device with IDCODE: 0x11004991 (manufacturer: 0x4c8 (), part: 0x08 vers: 0x1
Maybe it's an openFPGALoader issue? I'll post back here if I discover the problem.
This is the code that produces the first error: do { ret = libusb_bulk_transfer(dev_handle, DIRTYJTAG_READ_EP, rx_buf, 64, &actual_length, 1000); if (ret < 0) { cerr << "getVersion: read: usb bulk read failed " << ret << endl; return; } } while (actual_length == 0);
I wonder if it could be a libusb problem. The version I am using is 1.0.26-1
@phdussud, @machdyne I can confirm: libusb_bulk_transfer
produces a timeout error.
openFPGALoader -c dirtyJtag --detect
without anything connected fails to getVersion()
I have tried to increase timeout but with same effect: Have to check if something differs between stm32 version and pico
I cannot repro this problem on Windows, built and running against mingw-w64-i686-libusb
@phdussud could you provide your sdk version? I have cloned pico-sdk today: maybe something has changed?
I believe it was 1.4.0
@trabucayre I assume you rebuilt the firmware using the version of pico sdk you cloned> I flashed a pico board with the released (1.03) version from the github release section. It would be interesting to know if you can repro the timeout with that version.
I fired up my Asus tinkerboard running debian. I cloned the openFPGALoader, found all of the dependencies, built it and I can't repro the timeout on the pico board on this Linux plaform phdussud@tinkerboard:~/openFGALoader/build$ sudo ./openFPGALoader -c dirtyJtag --detect Jtag frequency : requested 6000000Hz -> real 6000000Hz phdussud@tinkerboard:~/openFGALoader/build$ sudo ./openFPGALoader -c dirtyJtag --freq 100000000 --detect DirtyJTAG probe limited to 16000kHz
OK. It looks like the pico sdk 1.5.0 is busted. I downloaded it, recompile DirtyJtag and I get the timeout. Both on Windows and Linux phdussud@tinkerboard:/openFGALoader/build$ sudo ./openFPGALoader -c dirtyJtag --freq 100000000 --detect getVersion: read: usb bulk read failed -7 DirtyJTAG probe limited to 16000kHz Jtag frequency : requested 100000000Hz -> real 16000000Hz writeTDI: read: usb bulk read failed -7 JTAG init failed with: Unknown device with IDCODE: 0x00080000 (manufacturer: 0x000 (CologneChip or efinix trion T4/T8), part: 0x00 vers: 0x0
@machdyne Have you tried to download my uf2 file from my 1.03 release? It works for me
With the uf2 for 1.03 release: openFPGALoader works fine. No error.
But since @machdyne wish to port pico-dirtyjtag to a custom board this test prove the issue isn't related to openFPGALoader and/or libusb.
I have tried to compile this release (or master branch since there is no new commit) manually and it's not working. I have tried pico-sdk 1.5.0 and 1.4.0 with gcc 11.3 and 12.2. With a manual build this issue remain true.
Sorry missed to do a git submodule update
after downgrading pico-sdk to 1.4.0. With this release the firmware is working.
Seems to have a regression somewhere between 1.4.0 and 1.5.0.
with this commit: the timeout error reappear but with this commit dirtyJtag works well.
Can confirm that the 1.03 release UF2 is working with detect and programming. I have been building with the latest pico-sdk.
It seems that tinyusb changed the behavior of tud_vendor_n_write. It does not send a packet back to the host if the buffer contents is less than 64 bytes. In the case of getVersion, the buffer is going to be 10 byte long so it isn't sent. I need to add a flush like so: cmd.c:201 / Send the transfer response back to host / if (tx_buf != output_buffer) { tud_vendor_write(tx_buf, output_buffer - tx_buf); tud_vendor_flush(); } I will do further testing to make sure everything works and release again based on the new sdk. Sorry about this.
Thanks for your feedback and for informations!
The release is done 1.0.5 When @machdyne or/and @trabucayre confirm that the issue is gone, I will close this issue Thank you for bringing this to my attention and for your investigation
I have tried with pico-sdk master branch and pico-dirtyJtag latest commit: getVersion()
works fine (not tested with a real device connected, but I thing it's enough to considering your last commit fix the issue.
@machdyne it's good to you too (with official pico board and werkzeug?
Thanks @phdussud
I can confirm that it appears to be working for me now on Werkzeug when building with the latest pico-sdk. I was able to program the ECP5 SRAM and onboard flash no problem.
One final question, I didn't see any mention of a license, is this project released under the same license as DirtyJTAG (MIT)?
Thanks for all of the help @phdussud and @trabucayre !
I should put a license. MIT is good.
Hi. I'm am trying to get this firmware working on a custom RP2040 board but I'm having some issues.
The device does show up after the firmware is loaded:
The target board has an ECP5 and only has TDO/TDI/TMS/TCK signals. I have tested the board with openFPGALoader using a USB Blaster cable and it's working as expected, but with the pico-dirtyJtag firmware I get:
Any advice appreciated.