search

purduesigbots / pros-cli

Command Line Interface for managing PROS projects. Works with V5 and the Cortex
https://pros.cs.purdue.edu/v5/cli
Mozilla Public License 2.0
109 stars 33 forks source link

Cannot upload binaries to V5 brain: couldn't find the response header in the device response #9

Closed Qrtn closed 2 years ago

Qrtn commented 6 years ago

Expected Behavior:

Successful upload of binary to microcontroller.

Actual Behavior:

Uploading /Users/jeffrey/Documents/hello/bin/output.bin to v5 device on /dev/cu.usbmodem1421 as hello to slot 1
Uploading slot_1.bin (/Users/jeffrey/Documents/hello/bin/output.bin) [#-----------------------------------]   2%
ERROR - pros.cli.upload:upload - Couldn't find the response header in the device response. Got  but was expecting aa55
  File "/usr/local/Cellar/pros-cli/3.1.2/libexec/lib/python3.7/site-packages/pros/serial/devices/vex/vex_device.py", line 69, in _rx_packet
    raise IOError(f"Couldn't find the response header in the device response. "
OSError: Couldn't find the response header in the device response. Got  but was expecting aa55

Steps to reproduce:

  1. prosv5 conductor new-project test-upload-mac
  2. cd test-upload-mac
  3. prosv5 make
  4. prosv5 upload

System information:

Operating System: macOS High Sierra (10.13.6)

PROS Version: 3.1.2

Additional Information

I installed PROS 3 using the instructions for macOS installs involving Homebrew for the latest release (3.1.2). Uploading works fine on another computer running Windows 10.

The percentage at which prosv5 upload fails and outputs the above error message varies from about 0 to 25.

Screenshots/Output Dumps/Stack Traces

Full output of prosv5 --debug upload

HotelCalifornia commented 5 years ago

I've updated the issue title to be more general, so that others having similar issues won't be misled into thinking this is purely a Mac issue. I'm also going to keep this open for now, for visibility.

To summarize: We believe there is an issue on some newer model computers that feature combined USB 2.0/3.0 ports. At this point, it is unclear if this is an issue on our end, or mainly a hardware/firmware issue, or if it's an upstream bug in pyserial. A lot of reported occurrences happened on Mac hardware, but this may also affect devices like the Microsoft Surface and certain newer Dell notebooks.

The workaround for this seems to be using a ~powered~ USB hub to connect to the V5. ~So far, USB 2.0 hubs are known to work. USB 3.0 hubs may work- if you have successfully used one in this capacity, please let me know.~

oliverwjay commented 5 years ago

I have not had any issues using this unpowered USB 3.0 hub.

HotelCalifornia commented 5 years ago

Made the title a little better than it was before

Qrtn commented 5 years ago

I just wanted to re-emphasize that I've been successfully uploading binaries on an Arch Linux VM on my MacBook Pro for a while now (uploading on Mac itself still doesn't work). So maybe it is an OS-specific issue. I'm really not sure if this has ever happened so far on other Windows laptops (with USB 3.0 ports) and desktops that I have tested.

Heasummn commented 5 years ago

I am also experiencing this issue on a Windows laptop. I have tried switching brains, ports and USB cables. Currently, I am reinstalling PROS. The exact error says: 

ERROR - pros.cli.upload:upload - Couldn't find the response header in the device response. Got  but was expecting aa55
  File "C:\Users\PROS\Jenkins\workspace\master95eda9d1\pros\serial\devices\vex\vex_device.py", line 109, in _txrx_packet
  File "C:\Users\PROS\Jenkins\workspace\master95eda9d1\pros\serial\devices\vex\vex_device.py", line 69, in _rx_packet
OSError: Couldn't find the response header in the device response. Got  but was expecting aa55
ERROR - __main__:main - name 'exit' is not defined
  File "C:\Program Files\Python36\lib\site-packages\click\core.py", line 535, in invoke
  File "C:\Users\PROS\Jenkins\workspace\master95eda9d1\pros\cli\upload.py", line 118, in upload

The directory C:/Users/PROS does not exist, but I doubt that is related to the problem. My download halts at 99%, but the updated code is still installed onto the robot. This problem happened randomly after PROS working consistently for 2 months. I will report back if reinstalling PROS solves the problem.

Bottersnike commented 5 years ago

If reinstalling PROS does not fix the problem can you also try (in this order):

DoctorFogarty commented 5 years ago

Hello,

I just started having this problem this evening on a Windows PC. I was building and deploying code successfully for 1-2 hours before the problem appeared. I was running a project updated to the Latest API and OKAPI.

Swapping USB, rebooting the PC/V5 system, and just restarting PROS didn't help. I even copied the entire project onto a flash drive and tried building and deploying the project on a different laptop and got the same error.

To continue doing any work I ended up opening up a project that was still on the 3.1.1 PROS API version.... and copied all of my SRC files into the older project. The project running the old API version built and deployed successfully.

Not sure what other information I could give that might help. It's very strange that everything worked fine and then something exploded and now nothing seems to work on the latest API version. I have not tried re-installing PROS yet.

Heasummn commented 5 years ago

I actually solved the issue, although the cause was rather silly. It seems like the firmware was corrupted, making a new project and copying the source code over solved all issues.

DoctorFogarty commented 5 years ago

I actually solved the issue, although the cause was rather silly. It seems like the firmware was corrupted, making a new project and copying the source code over solved all issues.

That's odd....why would anything we would do in the build/deploy process do anything to the firmware?

Heasummn commented 5 years ago

I'm unsure, I tried isolating every variable, and eventually I realized the only thing I hadn't tried was the code. My code is in a USB drive and I fear that the firmware may have gotten corrupted. On that note, does pros have some sort of clean function? A function that re-downloads the firmware and removes the entire bin folder.

DoctorFogarty commented 5 years ago

My code was on my hard disk. I know there is a clean build function in the pros menu....I tried that and it didn't work. I will say I never tried to make a new project on the latest API.

HotelCalifornia commented 5 years ago

I'm unsure, I tried isolating every variable, and eventually I realized the only thing I hadn't tried was the code. My code is in a USB drive and I fear that the firmware may have gotten corrupted. On that note, does pros have some sort of clean function? A function that re-downloads the firmware and removes the entire bin folder.

what firmware are you talking about? we have a clean function (by virtue of GNU Make) that will remove the contents of the bin folder (running prosv5 make clean does this alone, and running prosv5 make all will clean and then build).

Heasummn commented 5 years ago

I meant to say the PROS library itself. The files contained in /firmware were the ones that somehow got corrupted and were preventing the download. This was confirmed by making a new project and copying the folder over to the failing project, which solved the problem.

pieceofpie commented 5 years ago

I use a powered USB hub and now it can upload to the brain.

DoctorFogarty commented 5 years ago

I'm not sure how a USB hub would help in my case. I was using an older labtop with USB 2.0 ports when I saw this issue.

I created a new project on the latest API and haven't had the problem appear again.

HotelCalifornia commented 5 years ago

I created a new project on the latest API and haven't had the problem appear again.

Ok, glad you figured it out.

sentry-io[bot] commented 5 years ago

Sentry issue: PROS-CLI-3-1C

ThadHouse commented 5 years ago

I'm noticing this issue seems to be caused by how big a file is. I was having this issue, and both adding a line of code and removing a line of code fixed the issue. I wonder if there is something in the upload utilities having issues with certain file sizes.

If it helps, I'm attaching 3 binaries. The failure is the failure, the one with no extension is removing a line, the one with addedline is adding a line. Also attached is the project we're seeing the issue with.

vexprosuploadfailures.zip

CompPros.zip

HotelCalifornia commented 5 years ago

@ThadHouse that is the first issue I mention in this comment: https://github.com/purduesigbots/pros-cli/issues/9#issuecomment-451751459

A patch was merged in (thanks @Bottersnike) and will be available with the next release of the CLI.

oliverwjay commented 5 years ago

I just wanted to re-emphasize that I've been successfully uploading binaries on an Arch Linux VM on my MacBook Pro for a while now (uploading on Mac itself still doesn't work). So maybe it is an OS-specific issue. I'm really not sure if this has ever happened so far on other Windows laptops (with USB 3.0 ports) and desktops that I have tested.

I would like to add that I have also had no issues downloading when I boot into Ubuntu on the same computer that is experiencing issues in macOS.

HotelCalifornia commented 5 years ago

@Qrtn / @oliverwjay did either of you try using a USB hub when uploading?

oliverwjay commented 5 years ago

@Qrtn / @oliverwjay did either of you try using a USB hub when uploading?

From macOS I have never had success without a USB hub, and it works some days (I have not identified a pattern) using an unpowered USB3.0 hub.

From Ubuntu, it consistently works with or without the hub.

HotelCalifornia commented 5 years ago

(I have not identified a pattern)

I wonder if it's what @Bottersnike suggested here https://github.com/purduesigbots/pros-cli/issues/9#issuecomment-457858981 regarding using the firmware utility (or VCS) to configure the port first

oliverwjay commented 5 years ago

(I have not identified a pattern)

I wonder if it's what @Bottersnike suggested here #9 (comment) regarding using the firmware utility (or VCS) to configure the port first

I have not installed or used VCS from my mac, but my teammates occasionally do. If it is able to download code it will continue to download without issue at least until the robot is disconnected. When it doesn't work it will sometimes randomly decided to work again, but no pattern of restarting, power cycling, etc. has consistently made it work again.

kunwarsahni01 commented 4 years ago

I am consistently (after three/two uploads the issue occurs) having this issue on Mac OS Catalina (10.15.1). I have to either restart the V5 brain and or delete the program off the brain. I am using a MacBook Pro 2017 so I have to use a usb-c hub to upload my programs.

kunwarsahni01 commented 2 years ago

Have seen significantly less reports of this issue lately, so closing for inactivity.