phdussud / pico-dirtyJtag

MIT License
276 stars 38 forks source link

Issues with openFPGALoader on custom board #10

Closed machdyne closed 1 year ago

machdyne commented 1 year ago

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:

[10506.385827] usb 1-3.2: new full-speed USB device number 27 using xhci_hcd
[10506.487533] usb 1-3.2: New USB device found, idVendor=1209, idProduct=c0ca, bcdDevice= 1.10
[10506.487547] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10506.487554] usb 1-3.2: Product: DirtyJTAG
[10506.487559] usb 1-3.2: Manufacturer: Jean THOMAS
[10506.487564] usb 1-3.2: SerialNumber: DC6134A3633A8033

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:

$ sudo openFPGALoader -c dirtyJtag --freq 1000 test.bit
getVersion: read: usb bulk read failed -7
Jtag frequency : requested 1000Hz -> real 1000Hz
writeTDI: read: usb bulk read failed -7
JTAG init failed with: Unknown device with IDCODE: 0xeba89991 (manufacturer: 0x4c8 (), part: 0x5d vers: 0xe

Any advice appreciated.

phdussud commented 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!

machdyne commented 1 year ago

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
phdussud commented 1 year ago

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.

machdyne commented 1 year ago

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.

phdussud commented 1 year ago

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);

phdussud commented 1 year ago

I wonder if it could be a libusb problem. The version I am using is 1.0.26-1

trabucayre commented 1 year ago

@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

phdussud commented 1 year ago

I cannot repro this problem on Windows, built and running against mingw-w64-i686-libusb

trabucayre commented 1 year ago

@phdussud could you provide your sdk version? I have cloned pico-sdk today: maybe something has changed?

phdussud commented 1 year ago

I believe it was 1.4.0

phdussud commented 1 year ago

@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.

phdussud commented 1 year ago

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

phdussud commented 1 year ago

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

phdussud commented 1 year ago

@machdyne Have you tried to download my uf2 file from my 1.03 release? It works for me

trabucayre commented 1 year ago

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.

trabucayre commented 1 year ago

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.

trabucayre commented 1 year ago

with this commit: the timeout error reappear but with this commit dirtyJtag works well.

machdyne commented 1 year ago

Can confirm that the 1.03 release UF2 is working with detect and programming. I have been building with the latest pico-sdk.

phdussud commented 1 year ago

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.

trabucayre commented 1 year ago

Thanks for your feedback and for informations!

phdussud commented 1 year ago

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

trabucayre commented 1 year ago

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

machdyne commented 1 year ago

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 !

phdussud commented 1 year ago

I should put a license. MIT is good.