Any chance this is with RobotC V 3.03 or earlier? There was an obscure bug in that version that would cause download problems under certain conditions. If so, upgrade to RobotC V3.04 and it will work. As you have found, changing a line of code will also temporarily fix it.
We’ve had this exact same problem numerous times (with multiple Cortexes – at least 3) using v3.04. I’ve never tried simply changing a line of code, but trying to download the program has given us the same error, and it always downloaded until around 55% or so, then would stop and give us the flash write error.
The only way we ever tried to fix it that worked was to completely re-install ROBOTC.
Yep, I was using ROBOTC 3.03, and have since upgraded to 3.04.
I’ll try downloading the code again when I see the robot.
Ive had the flash write error many times now, but it turns out the problem for me is the programming cable. Try changing the cable, it might be the cable thats the problem.
We had the same problem the afternoon of registration day. We also finally changed the serial download cable & the problem disappeared. But later that night we started getting the same problem at the tournament with the new cable. We went back to school & tried a new cable & could download again. What I’m not sure about is how can 2 cables that worked fine til that day both suddenly give us problems after working for a few hours. We are using RobotC vs 3.04.
We too tried switching cables. We switched cables, switched remotes, tried to re-download master code and firmware, and none of those worked even once. We weren’t able to fix it until we uninstalled and re-installed ROBOTC v3.04 and all the drivers.
There can be more than one cause of download errors. The symptoms that Simmons 2.0 described exactly matched those of a known problem with RobotC version 3.03.
Using the serial download cable through the joystick.
Changing a line of code or compiling with different optimization and the download works.
I’m 99% sure that upgrading to RobotC 3.04 will solve his issue.
There are other things that can cause a communications error, if you look at the process to send the code to the cortex it’s amazing that it works at all. Here are the steps that are happening (somewhat simplified).
RobotC sends a packet of data to the virtual com port on the PC.
The prolific driver turns the serial packet into a USB packet and transmits using the USB->serial adapter.
The prolific USB adapter turns the USB request back into an RS232 serial packet.
The orange RS232 programming adapter changes the packet from having RS232 logic levels to TTL logic levels and send to the joystick over the flat serial cable.
The joystick receives the data packet and checks if it is communication for the joystick or the cortex, if it is for the cortex it converts into a USB packet and sends using either WiFi or the USB A-A cable.
The supervisor processor in the cortex receives the USB data packet and determines if it is to be used locally (eg. asking for firmware version number) or for the user processor. If the data is for the user processor the packet is transmitted through another serial link to the user processor.
The user processor receives (finally) the request and takes action.
You can see that there are many steps and many physical connections (I count 6 in my setup) that can come loose or be intermittent. Cables can be bad but I would think finding two bad cables on the same day unusual.
We have had 5 official versions of RobotC since September 1 so it would not surprise me if somewhere an install or driver was corrupted. It should not happen (I installed every version over the previous one and had no issues) but we are dealing with windows here and anything is possible. Jordan’s problem certainly sounds like a damaged or out of date dll or driver.
jokai, did you try the bad cables on another PC? during competition is the worse time to debug this type of problem, it could have been something other than the cables.
I’ve seen some errors from our kids as well and I pinned it down to having a competition controller switch plugged into the joystick. This did not used to be a problem with last year’s versions of Robot C.
When you take out the competition controller it generally works. (I say generally)
Using v3.04 of Robot C but not sure the version of the prolific driver but it was a new version given to us. It’s a brand new Joystick, Cortex, and set of Vexnet USB keys too. Same old programming cable though but has been shown to work.
(This is the Foster made competiton controller switch and is a bit easier to reset than via software panel in RobotC)
Yes, I have one of those and now you mention it I did notice an issue a couple of weeks ago helping the students download autonomous code, we had to disconnect the switch (an official one) to get it to work. I will look into that when I have a chance.
Here’s mine, old cat 5 cable, some proto board, couple of switches I had laying around and a CF card case hacked with a utility knife.
jpearman, I haven’t tested my serial cables on another computer yet. We’re currently building a new robot & will test them on that one. We’ve found the cables work when we use the sample programs so we want to test them with longer code. We are using RobotC vs 3.04. We had major downloading issues with vs 3.03 & had notified RobotC so they immediately came out with vs 3.04. I have notified them about this thread & the issues that I’ve been having with vs 3.04. Some how we’ve been managing to get around these issues but after reading this thread, I’m wondering if a line in my code could be affecting it.
So to reiterate, this thread was to inform everyone about download issues with V3.03 and earlier. The download bug in that version was easy to reproduce after the failure mechanism was understood, and CMU has fixed it. V3.04 is very stable IMHO for downloads, I have done numerous downloads over the last month with a variety of hardware and the only problems encountered have not been related to RobotC but other factors.