YS1 LED flashing, dmesg states ` usb usb3-port1: unable to enumerate USB device`, doggle not listed in devices

[anoduck]

USB USB3-Port1: Unable to enumerate USB device

Preliminaries

OS: Kali Linux Rolling Release Python: Python 3.11.8 Rfcat: Pulled from Master on 3-20-24 SDCC: 4.2.0

Intro

I just purchased this YS1 a few days ago, it arrived yesterday in mint condition. Since attempting to use it, I have encountered the following issues in chronological order.

1. resetup():USBError(110, u'Operation timed out')

This error is sporadically intermittent, therefore cannot be relied on for reproduction, and currently thought of as a fluke.

2. IOError

This error occurred once or twice, then ceased to occur altogether. The logs of this error have been lost, and therefore it is assumed to be an error caused by a loose usb connection.

3. Device randomly and unexpectedly entered into bootloader mode

The LED of the device came on and stayed on. Per documentation, it was concluded this indicated the device had entered bootloader mode. This was odd because nothing was done to place the device in bootloader mode, except simply plugging it in. Due to the two previous errors, it seemed ample opportunity to flash the device, which was performed smoothly without error.

4. Device LED flashing and device is not listed in system

At the end of flashing the device it stated that device had been reset, so an attempt to use rfcat -r was made, but rfcat was not able to locate the device. lsusb did not include the YS1, and then dmesg was discovered to contain the following log of entries.

[23092.755880] usb 3-1: new full-speed USB device number 35 using ohci-pci
[23106.139759] usb 3-1: device descriptor read/64, error -71
[23119.659631] usb 3-1: device descriptor read/64, error -71
[23119.955630] usb 3-1: new full-speed USB device number 36 using ohci-pci
[23133.339505] usb 3-1: device descriptor read/64, error -71
[23146.859353] usb 3-1: device descriptor read/64, error -71
[23146.967412] usb usb3-port1: attempt power cycle
[23147.663369] usb 3-1: new full-speed USB device number 37 using ohci-pci
[23147.696064] usb 3-1: device descriptor read/8, error -62
[23147.828060] usb 3-1: device descriptor read/8, error -62
[23148.107354] usb 3-1: new full-speed USB device number 38 using ohci-pci
[23148.140053] usb 3-1: device descriptor read/8, error -62
[23148.278000] usb 3-1: device descriptor read/8, error -62
[23148.383399] usb usb3-port1: unan array and a length, thble to enumerate USB device

The device was unplugged and plugged back in, but the error persisted. An attempt was made to place the device back in bootloader mode by jumping between GND and DC, but this had no effect on the device, and it remains flashing.

It is unclear what to attempt next, but there is concern a debugging device will need to be acquired in order to further troubleshoot the matter.

[anoduck]

Progress!

Have not been successful using POGO pins to put the device in bootloader mode, BUT jumping the header worked just fine and dandy. dmesg recognized the device as "YARD Stick One Bootloader", which is good. Continued with flashing device, and everything worked smoothly.

Then, the device became non-responsive again.

Going strictly by the book

Starting to think this has to do with the more recent version of sdcc, which is 4.2. As, the developer recommends dropping down to Debian stretch, which reached EOL in 2020.(Am I really that far behind the curve?) Unsure about stretch, but bullseye used sdcc version 3.8, and it appears this is the closest one can get, since iso images for stretch appear to be hard to come by. Powering up a VM and seeing if magic happens.

Below is the dmesg output before, during, and after flashing the device.

[36443.730552] usb 3-1: new full-speed USB device number 49 using ohci-pci
[36443.931704] usb 3-1: New USB device found, idVendor=1d50, idProduct=605c, bcdDevice= 0.10
[36443.931725] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36443.931734] usb 3-1: Product: YARD Stick One Bootloader
[36443.931741] usb 3-1: Manufacturer: Great Scott Gadgets
[36443.931746] usb 3-1: SerialNumber: 000001
[36443.939736] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
[36546.595774] usb 3-1: USB disconnect, device number 49
[36547.205468] usb 3-1: new full-speed USB device number 50 using ohci-pci
[36560.593327] usb 3-1: device descriptor read/64, error -71
[36574.085186] usb 3-1: device descriptor read/64, error -71
[36574.373182] usb 3-1: new full-speed USB device number 51 using ohci-pci
[36587.757031] usb 3-1: device descriptor read/64, error -71
[36601.248904] usb 3-1: device descriptor read/64, error -71
[36601.356965] usb usb3-port1: attempt power cycle
[36602.052896] usb 3-1: new full-speed USB device number 52 using ohci-pci
[36602.085673] usb 3-1: device descriptor read/8, error -62
[36602.217667] usb 3-1: device descriptor read/8, error -62
[36602.504909] usb 3-1: new full-speed USB device number 53 using ohci-pci
[36602.537654] usb 3-1: device descriptor read/8, error -62
[36602.669647] usb 3-1: device descriptor read/8, error -62
[36602.776918] usb usb3-port1: unable to enumerate USB device

Comment:

In my excitement over a potential resolution, it was completely forgotten how much faster and easier it is to perform this type of work in docker rather than Virtualbox.

[anoduck]

Attempting to build the module with bullseye looked good at first, but ended in failure.

]0;vboxuser@Bullseye: ~/Sandbox/rfcat/firmwarevboxuser@Bullseye:~/Sandbox/rfcat/firmware$ make installRfCatYS1CCBootloadercd firmware/lslcd Sandbox/rfcat/sudo suapt search python2lscd rfcat/git clone https://github.com/atlas0fd00m/rfcat
cd Sandbox/git clone https://github.com/atlas0fd00m/rfcat
cd rfcat/lsapt search python2sudo sucd Sandbox/rfcat/llscd firmware/make installRfCatYS1CCBootloadersudo make installRfCatYS1CCBootloadercd firmware/make installRfCatYS1CCBootloader[1@s[1@u[1@d[1@o[1@ 
[sudo] password for vboxuser: 

==RfCatYS1CCBootloader.hex building==
sdcc -Iinclude -DBUILD_VERSION=`../revision.sh` --xram-loc 0xF000  --code-loc 0x1400 appFHSSNIC.c chipcon_usb.rel chipcon_usbdebug.rel chipcon_dma.rel bootloader.rel cc1111rf.rel global.rel cc1111_aes.rel -DYARDSTICKONE -DCC1111 -DUSBDEVICE
packihx <appFHSSNIC.ihx >bins/RfCatYS1CCBootloader.hex
packihx: read 629 lines, wrote 1211: OK.
if [ ! -c /dev/RFCAT_BL_YS1 ] ; then ../rfcat --bootloader --force -S && sleep 1 ; fi ;
Traceback (most recent call last):
  File "../rfcat", line 11, in <module>
    from rflib import *
  File "/home/vboxuser/Sandbox/rfcat/rflib/__init__.py", line 8, in <module>
    from .chipcon_nic import *
  File "/home/vboxuser/Sandbox/rfcat/rflib/chipcon_nic.py", line 11, in <module>
    from past.utils import old_div
ModuleNotFoundError: No module named 'past'
make: *** [Makefile:380: installRfCatYS1CCBootloader] Error 1
]0;vboxuser@Bullseye: ~/Sandbox/rfcat/firmwarevboxuser@Bullseye:~/Sandbox/rfcat/firmware$ exit
exit

Script done on 2024-03-21 01:32:40-04:00 [COMMAND_EXIT_CODE="2"]

Back to the drawing board... Oh, Lookee FAQ! (Several minutes later...) So, your telling me it's has nothing to do with the firmware or the dongle, it's my usb3.0 port that is the source of all my errors?

Well, I have tried all ports in the front, and one on the back. I guess I will just have to move to a different computer then.

(... a few hours later...)

That didn't make any difference, plugged it in, and the doggle went right to flashing, never being recognized by the OS. OpenBSD just disabled the port flat out.

uhub3: device problem, disabling port 4

Now I am stuck, and I really don't want to go about trying to revive an old x86 or dual core.

[anoduck]

Another day, and another attempt. Since there is a well established history of issues concerning kali attempting to run rfcat/YDS1, there is the possibility this could be what is causing the problem. So, today, I plan on creating a podman image with ubuntu specifically for use with rfcat. Ubuntu was chosen because it was suggested by the maintainer of this repo in a previous issue.

---

Well, either podman didn't forward the usb device as it was believe it should, or running ubuntu in a pod container made no difference.

Trying VirtualBox next, although with reservations.

[anoduck]

Ubuntu on VBox could not even detect the device, regardless of it being forwarded to the virtual instance. This is not the desired result, and until someone (@atlas0fd00m, @AdamLaurie, anyone) enlightens the situation, I am stuck.

[anoduck]

All of this work, when the answer lied in #154 the entire time. Not fun times at all. I want those hours of my life back.

Please update the readme.

[atlas0fd00m]

i'm sorry for your pain and frustration, @anoduck .

what could we put in the README that might have helped you? it's fresh in your mind, would you like to write something up and either submit it as a PR, or place it here and i'll update it?

@

[anoduck]

@atlas0fd00m Whatever, is easiest for you. People that can do what you do are in very high demand. Proverbially speaking, you make MacGyver look like a kid playing with LEGOS. I don't mind submitting a pull request, and helping out anyway I can. There are just some basic points that need clarification before I could begin to write up something.

1. Generally speaking, what is rfcat_bootloader, what is the purpose of its existence, and Why did you write it?
2. Does rfcat_bootloader replace the make process of the bootloader? (It looks like it does.)
3. Assuming the above to be true, does this mean all we have to do is a) install rfcat, b) download the appropriate hex file, and c) run rfcat_bootloader.
4. Assuming 2 and 3 are true, would it be alright if I wrote up a bash or python script to automate this? Sort of a yardstick firmware for dummies like me?

These are the basic questions I came away with from the experience.

[atlas0fd00m]

thank you for your kind words :) i'm deeply humbled by them. there are several other amazing people who have contributed significantly to RfCat over the years. one of them, iinm, MajorMalfunction ( @AdamLaurie ), who provided the Bootloader code (firmware and supporting host-tool named bootloader). before that, every time you flashed a dongle, it required either a GoodFET or a TI programmer.

the bootloader code on the dongle is the first code that starts up. it checks for a few triggers (like two pins being connected, or a setting sent in by RfCat python code), and if they are not set, it jumps into the normal firmware at a hard-coded address. this behavior/setup is why the raw firmware and firmware intended for loading with a bootloader have to be different, because the base address of the RfCat firmware are different, to leave room for the bootloader code to live at address 0.

because RfCat scripts/exes are installed in the common path, i renamed bootloader to rfcat_bootloader to avoid any ambiguity, and make sure it was easy to figure out.

you may wish to look through the build targets of firmware/Makefile, although i can understand it's not easy to read until you get deep into it. keep in mind that the Makefile is trying to make all these things easy, using multiple programmers to load the initial bootloader code, as well as supporting multiple dongles with slightly different firmware (like, the LED on the DonsDongle is on a different pin than the ChronosDongle, and the YS1 has amplifiers that none of the others do)

1) rfcat_bootloader is the host-based python script which handles interfacing with the bootloader firmware stub on the RfCat dongle. when the dongle is in bootloader mode, it expects several commands to handle programming and verifying, etc.... this script handles the low level details 2) rfcat_bootloader is part of the Makefile build process. first, SDCC compiles and creates the firmeware images... next RfCat is placed into bootloader mode, next rfcat_bootloader erases the firmware location and writes the new firmware there, then verifies that it copied correctly. 3) sorta? when you get an RfCat dongle, it should already be flashed. installing RfCat on your host should be all you need. if you bought a dongle that is fresh (no code whatsoever)... you need to attach a programmer (hardware like a GoodFET/GreatFET or TI programmer) and run make installys1bootloader or make installys1bootloadercctool (for either the GoodFET or the TI ChipCon programmer, assuming the dongle is a YS1) 4) i'd consider any contribution you wish to make of value. keep in mind, i may ask you to change things a bit. for example, most of these things already are part of the Makefile. you would learn a lot and probably enjoy making your own script. and that may be very valuable to you (and us if you continue to want to contribute!). but it's entirely possible i'd ask you to look at the Makefile, figure out how things work, improve it if need-be, and write a document on how to do the things you want to do with what's already there.

does that all make sense?

thanks for your investment in RfCat! @

[anoduck]

@atlas0fd00m I got you, it makes sense, and I appreciate you taking the time out of your day to explain it all. Learning is what it is all about, and the more you learn, the more you want to learn.

I purchased my YardStick One used, and it did work the first time I plugged it in. So, it is safe to assume it was preflashed. I hate having to admit it, but I am exactly where I was a few days ago, receiving the exact same timeout errors. In previous issues, this was resolved by using sdcc version 3.5.0 to flash the bootloader. As previously stated, Kali currently provides sdcc 4.2.0, and more than likely installing 3.5.0 would have to be manually performed (It is not like that is a problem).

What doesn't make sense is why does it work one time, and then later on fail at another time?

[anoduck]

I moved the device from the rear usb port back to the front, and since, it has worked like a top. I will just use the front usb port from now on.

[anoduck]

@atlas0fd00m I don't usually do this, but you came across as a very nice person, and I appreciate the response. It gave encouragement, and meant something.

[atlas0fd00m]

thank you again! that's great feedback, and we could all use more of that.