Unable to start a detection on UrJTAG

[jeanthom]

Raspberry Pi Pico connected to a generic XC6SLX16 development board, work OK with a (patched) openFPGAloader:

sudo ./openFPGALoader --cable dirtyJtag --detect
write to ram
Jtag frequency : requested 6000000Hz -> real 6000000Hz
idcode 0x44002093
manufacturer xilinx
model  xc6slx16
family spartan6

But on UrJTAG:

UrJTAG 2021.03 #
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

jtag> cable dirtyjtag
jtag> detect
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
USB read failed (timeout expired ?)
(it goes on and on for a while like this)

[jeanthom]

This is what happens just after I initialize DirtyJTAG inside UrJTAG.

[phdussud]

I am working on a Windows machine. I had to build urjtag per your instructions. It won't build as configure because of libintl.dll.a. I turned off nls in autogen.sh I modified the relevant line to: ./configure --enable-maintainer-mode --disable-nls "$@"

This gave me an error free build. This is what I got $ jtag

UrJTAG 2021.03 #4877e7ab Copyright (C) 2002, 2003 ETC s.r.o. Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware! Type "quit" to exit, "help" for help.

jtag> cable dirtyjtag jtag> detect IR length: 8 Chain length: 1 Device Id: 01000001000100010011000001000011 (0x41113043) Manufacturer: Lattice Semiconductors (0x043) Unknown part! (0001000100010011) (P:/msys2-64/mingw32/share/urjtag/lattice/PARTS) jtag>

I verified that the part I am using isn't in the PARTS file, so I think the dirtyjtag is working for me with my version of urjtag and Windows 10. Please let me know if you have other clues.

[phdussud]

I see that the USB packet that isn't ACKed is a setup SET_INTERFACE alt_setting:0 interface:0 I wonder if tinyUSB has a problem with this. I am not sure if Windows sends such packet. I don't think it is necessary to send it.

[jeanthom]

You're right, I was thinking it had to do with bulk transactions. That might be related to the lack of tud_vendor_control_xfer_cb implementation in the code? I'll try a fix tonight.

[jeanthom]

Was too impatient so I tried this fix:

bool tud_vendor_control_xfer_cb(uint8_t rhport, uint8_t stage, tusb_control_request_t const * request)
{
  // nothing to with DATA & ACK stage
  if (stage != CONTROL_STAGE_SETUP) return true;

  switch (request->bmRequestType_bit.type)
  {
    case TUSB_REQ_TYPE_CLASS:
        return tud_control_status(rhport, request);
        break;

    default: break;
  }

  // stall unknown request
  return false;
}

and it worked! I'll try to make it prettier tonight.

[phdussud]

I am curious about 2 things. Are you using the pico sdk 1.2? Do you know if the picoprobe FW works for you? The USB code from this project has been lifted from the picoprobe sources... I just checked and they have no special code for control transfer, it is just implemented by the code from tinyusb. I believe the code you are adding should be put in the tinyusb library, since it handles a completely generic request. In any case, I am glad you found a work around, as I don't have a Linux system.

[jeanthom]

I'm using commit bfcbefafc5d2a210551a4d9d80b4303d4ae0adf7, which is 1.2 indeed. I haven't tried picoprobe yet... This kind of code for handling control requests can actually be found in my DirtyJTAG repo: https://github.com/jeanthom/DirtyJTAG/blob/a36b0cc039d05f820583cb1553b4cf8c17775fff/src/usb.c#L226-L240

I based this snipped off this: https://github.com/hathach/tinyusb/blob/master/examples/device/webusb_serial/src/main.c

I guess this is needed because in the UrJTAG driver I added some code to claim the USB interface, which supposedly trigger some setup requests on Linux?

[phdussud]

Thanks for quick reply. It seems that that the code you just wrote is a little different the webusb example. The webusb example only handles the case TUSB_REQ_TYPE_CLASS & CDC_REQUEST_SET_CONTROL_LINE_STATE which isn't relevant for us. Shouldn't you stall on TUSB_REQ_TYPE_CLASS as well?

[jeanthom]

Hi Patrick, I did some more testing. It turns out we can ditch the switch, as the following callback code is sufficient to get it running:

bool tud_vendor_control_xfer_cb(uint8_t rhport, uint8_t stage, tusb_control_request_t const * request)
{
  if (stage != CONTROL_STAGE_SETUP) return true;
  return false;
}

Seems like we're not the first people to experience this problem: https://github.com/hathach/tinyusb/issues/592

[phdussud]

Thank you very much for the fix.