So I’ve seen some threads about communication problems before, but the issues seemed to be Mac related, not PC.
Cortex Version: Unknown(I forgot to look)
RobotC Version: 3.51 on Windows XP
So the problem we’re having is downloading a program from USB → Cortex. We tried it on a school computer, got it to download half the Cortex firmware, but RobotC crashed while “Erasing Flash”. Then we tired to download it again, and it successfully downloaded the firmware. But after that, we weren’t able to ever get “Robot Comm”(or something like that) in the “View → Detailed Preferences → Platform → Communication Port”.
So we tried it on a different computer (which had no permission restrictions like the school computers), and we were able to get some sort of “RC” driver to install, which showed up under “Communication Port”, but alas when we tried to download firmware/program, a communication error occurred, and “Test Communication Link” didn’t respond anything.
Could be a number of different issues, the firmware utility Liam referenced does basically the same job as ROBOTC downloading the master firmware. If you have for some reason blown away the master firmware then you will need to push the “config” button whilst powering (plugging in the USB cable) the cortex to put it into bootload mode. Alternatively, if the cortex is seen as a CDC_RC_Controller, that usually indicates the VEX communications port driver is not installed correctly, here is a screenshot from the troubleshooting help.
[ATTACH]6878[/ATTACH]
Instead of rehashing all the troubleshooting steps here, click on “troubleshooting help” from the main “Getting started with ROBOTC” page that is displayed when you first startup ROBOTC, you may have to select “show getting started” from the help menu if you are internet connected.
could this problem affect only one of our three cortexs? We have one that was having connection issues until we backed up to a archived version of RobotC.
On the same note, has anyone noticed an increase loss in connection while the programming cable is attached. It makes it really hard to program when it disconnects. It works fine with the USB A-A.
I do most programming with the joystick and cortex connected with the USB cable and the USB-serial cable connected to the joystick, it saves on batteries. I have not experienced problems with the VEXnet keys attached unless the competition switch is also connected.
Is the hardware rev different ? (on the base, A3, NC2 etc.)
There could be minor differences in the USB signal integrity, the USB arbitration code does keep changing with master firmware, 3.16 was different to 3.21 and 3.21 worlds.
Which version did you have problems with? Which version did you downgrade to?
I have noticed problems doing wireless downloads, typically I have seen them in what I suspect is a congested wireless environment. Specifically when we have 2 or more robots active in our meetings or at a competition when there are many robots. The Organizers of the Colorado tournaments have indicated no one should be using wireless downloads in the pits as it has been linked to weird behavior. My team refused to heed the recommendation initially and then switched entirely to using the USB cable vs Vexnet keys as downloads were so much faster and more reliable in the pit area.
Our remote control worked o.k. it seems to hit downloads more often. which makes some sense due to the amount of data being transferred in each scenario.
When we have only one active robot we can often successfully transfer code, but we have learned to switch to USB at the first failed transfer.
The other link we have found is that when the usb modules get really warm they tend to fail more often, swapping them out usually resolves the issues, so we keep spares on hand when doing a lot of driving.
I should add I had a lot of problems at a BEST competition recently but when I got the teams going with good equipment and gathered up all the 'suspect handsets, cortexes and keys I found through meticulous testing I had 4 bad keys and all the handsets / cortexes worked with the latest firmware (3.2.3) for both easy C and Robot C
Alright, I got it working today! Once I got the computer recognizing the Cortex as a “Vex Robotics Comm” (or w/e the correct name is) in the Device Manager , I was able to download the RobotC firmware, which then finally allowed me to download the program.
I had an interesting (if not fun) experience related to this problem (I think) today. I was troubleshooting my serial port code which had stopped working in 3.51 when after restoring the previous version of Robot C 3.08 and confirming my code still worked. I installed 3.51 on a different computer. Both computers are running Windows 7. When I tried to install the Updated Master code using Robot C, Windows decided my Cortex was a USB input device and failed to load the Firmware. after restoring functionality on my laptop (under RobotC 3.08) I tried again - same results, Finally I used the VexNet firmware update utility on this page
and was able to successfully load the master code. it Appears there is some interaction with Windows 7 & the method Robot C uses to load the firmware which does not work, at least for some of us.
The problem I encountered was with the cortex plugged into the PC, I haven’t had problems with the programming cables yet (thankfully) I got suspicious of what what happening because of the various problems people have had, and also as on that particular computer every time I use the KVM to switch the monitor / keyboard to another computer it very quickly switches the video resolution. When researching that problem I found that Windows 7 constantly polls devices plugged in to determine their “state”. So I watched as the firmware install utility ran and sure enough the Cortex which had been installed correctly as a comm device suddenly appeared as a USB input device. I would venture a guess that there is a certain amount of functionality in the firmware which when absent fakes Windows into thinking the Cortex is a USB input device.
But thankfully the Firmware upgrade utility worked.
I do have a problem I need to document in another thread I could use your help on though. I should have it posted soon. Problems with my serial port project and Robot C 3.51
The cortex switches from a USB CDC device (communications class) to the HID (human interface device) to load the master firmware. The HID mode is part of the bootloader, code that is rarely if ever updated, and not part of the master firmware. The HID mode was used for all communication prior to firmware V3.0, it was flakey to say the least. I always have issues updating firmware using my Mac, it will not work at all using the built in USB ports, I use an external ethernet to USB server anytime I need to use the Mac to update firmware, it’s a real PITA. Not had significant problems using real PCs, once in a while one in the lab at school will not work but we usually assume it’s a driver issue and just switch to another PC. We have 75 ROBOTC licenses at the school and not all machines have been updated to 3.51 yet, waiting for the next version which should be out very soon.
3.54 came out over the weekend, I loaded it on one PC at home. But the link was flaky, the first attempt early this morning resulted in 3.51 being D/L’d again and of course no upgrade was necessary (I used the Robot C interal update method). The web page also list 3.54 but was linked to the 3.51 version. Later this afternoon the internal update link seemed to work, but when I tried the web page (to save a copy ) the link still pointed to 3.51 I’m sure it will be resolved soon. I did open a trouble ticket. So the Migration Issues thread I just started here : https://vexforum.com/showthread.php?p=319275#post319275
was based on testing with both 3.51 and 3.54
