Soft reset not working on Ubuntu 20.04 LTS - Please help

Status
Not open for further replies.
D

danozdirekt

New member
I have been stumped on this issue for quite a while now. It seems that line 337 in teensy_loader_cli.c throwing an error when opening USB device
https://github.com/PaulStoffregen/teensy_loader_cli/blob/master/teensy_loader_cli.c

serial_handle = open_usb_device(0x16C0, 0x0483);

Example output:

root@ubuntu:/home/ubuntu/teensy_loader_cli# ./teensy_loader_cli --mcu=TEENSY41 /home/ubuntu/firmware.hex -v -s
Teensy Loader, Command Line, Version 2.2
Read "/home/ubuntu/firmware.hex": 355478 bytes, 4.4% usage
Error opening USB device: No error
Waiting for Teensy device...
(hint: press the reset button)

The only way I seem to be able to remotely upload my code is by pressing the button on the teensy, but this is not viable for my situation. I know that there is a workaround if using raspbian which I have used before

SERIAL_TEENSY_DEVICE=find /dev/serial/by-id/ -name "usb-Teensyduino*";
echo "-> Performing soft resset (baud = 134 hack). $SERIAL_TEENSY_DEVICE";
lsusb | grep Teensy;
stty -F $SERIAL_TEENSY_DEVICE 9600
sleep 1;
stty -F $SERIAL_TEENSY_DEVICE 134
sleep 1;
lsusb | grep Teensy;
echo "-> Should be ready to program...";
sudo ./teensy_loader_cli --mcu=imxrt1062 -v -w TEENSY4_CODE.hex

But I really need to get this command working on Ubuntu 20.04. Is there anything anyone can do to please help me out ? Does anyone know of any other workarounds I could use ?

Thanks,
Dan
 
You could try replacing these lines 344 and 345 in teensy_loader_cli.c
Code: 
	char reboot_command = 134;
	int response = usb_control_msg(serial_handle, 0x21, 0x20, 0, 0, &reboot_command, 1, 10000);

with these

Code: 
	char reboot_command[] = {0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08};
	int response = usb_control_msg(serial_handle, 0x21, 0x20, 0, 0, reboot_command, sizeof reboot_command, 10000);

and seeing if it makes a difference. That's what I've done in Raspbian to get the soft reboot to work with my Teensy 4.x's. Now, granted, under Raspbian the unaltered code got past the open_usb_device() call that you say you're getting caught on, and then died with a broken pipe error on the usb_control_msg() call. Still, it's easy enough to try and see if it makes a difference in your situation.
 
There's no error about *why* open_usb_device() failed to open the device. All the cases where it finds a matching device print errors. The absence of such an error suggests teensy_loader_cli isn't finding a matching device to open.

So your first step is to just run "lsusb" and check whether you really do have a Teensy detected with ID numbers 0x16C0, 0x0483. If Teensy isn't on the list of usb devices, then something is wrong that can't be fixed by teensy_loader_cli.

If you do see 16C0:0483 with lsusb, then the big question is why would teensy_loader_cli not try to open it. I'd recomment uncommenting this:

Code: 
	//printf_verbose("\nSearching for USB device:\n");
	for (bus = usb_get_busses(); bus; bus = bus->next) {
		for (dev = bus->devices; dev; dev = dev->next) {
			//printf_verbose("bus \"%s\", device \"%s\" vid=%04X, pid=%04X\n",
			//	bus->dirname, dev->filename,
			//	dev->descriptor.idVendor,
			//	dev->descriptor.idProduct
			//);

Then compare the list of devices it prints to the list you get from running "lsusb" or "lsusb -t".
 
Thanks for the replies guys. Today I setup a fresh raspberry pi installation with Ubuntu 20.04 and was able to get everything working properly with Silverlocks code change suggestion (thank you!).

What I suspect might be the cause of the USB error is that the teensy4.1 may not have been plugged into the raspberry pi correctly. This is something I have no visibility of as the device is remote. I will be able to test again with the remote device tomorrow to hopefully confirm.
 
Status
Not open for further replies.
Back
Top