VEXnet 2.0, Oct-2014 firmware - readme

(October 20 2014)

I’m seeing lots of confusion about the new master firmware that was released recently. This post will hopefully explain what’s going on and what you should do to keep working with your cortex.

First a small recap.

The cortex contains two micro-controllers, one we call the master processor, this is responsible for the most important functions of the cortex such as VEXnet and disabling motors during competition when autonomous and driver control periods end. The second is called the user processor, this is where the code we write in EasyC and ROBOTC (and PROS and ConVEX) runs. It has the code that reads the analog and digital ports, the UARTs, the I2C bus for the IMEs and requests that the master processor run motors at a given speed.

Both processors need firmware, the master processor can be programmed by the VEXnet upgrade utility but, for our convenience, both EasyC and ROBOTC contain the latest version of the master firmware that was available on the date that they were released. When a new version of master firmware is released there will be a short period when both EasyC and ROBOTC will have an old version, both companies usually release an update shortly after VEX releases new master firmware.

Last week VEX released new master firmware, V4.23.
ROBOTC V3.63 and V4.26 have the older master firmware V4.22
EasyC V4.1.2.7 also contains master firmware V4.22

The joystick also has a micro-controller that needs firmware, this is different firmware than that loaded into the cortex but usually has the same version number. When VEX releases new master firmware for the cortex a new version for the joystick is released as well, both of these are contained within the vexnet upgrade utility. The new joystick version is V4.23.

Now to the part that has been causing problems recently.

The VEXnet 2.0 keys also contain firmware that can be upgraded, this was not the case with the old black VEXnet 1.0 keys (which, although they contained a microprocessor, was programmed once at the factory by the manufacturer). VEXnet 2.0 has been at version 1.43 since April, this was the first stable release that we upgraded everyone to at worlds.

Last week V1.46 was released for the VEXnet 2.0 keys, this was a “security update” and due to that fact it was hard for VEX to maintain backwards compatibility with the existing cortex and joystick master firmware. I’m not going to explain what was changed but having though about the issue and looked into the changes I don’t think they had much choice but force an upgrade of both keys and cortex.

Cortex/joystick V4.22 can only use VEXnet 2.0 keys that contain V1.43.
Cortex/joystick V4.23 can only use VEXnet 2.0 keys that contain V1.46.

This is not an ideal situation, there is no visible indication as to the version in the VEXnet keys and we cannot read that in EasyC and ROBOTC.

If you use V1.43 (old) VEXnet 2.0 keys on a cortex/joystick with new master firmware the leds will flash as follows.

(almost accurate, but not quite, simulations)

If the paired cortex is turned off.

If the paired cortex is turned on.

Two red leds will flash, the new firmware understands these are older firmware keys and will not link.

Using updated VEXnet 2.0 keys with an old cortex/joystick is a bit tricker. The older master firmware does not understand the changes that have been made so the key tricks the cortex/joystick into rebooting. Both try to communicate with the VEXnet key and you get a similar effect to not being able to connect with each other. It look sort of like this (not an exact simulation, too time consuming to do).

So what do we need to do.
The preferred thing to do is upgrade all VEXnet 2.0 keys to V1.46 and cortex/joystick master firmware to V4.23. This needs to be done to all systems that will share the VEXnet keys, if you only do some systems then you may start mixing the incompatible versions. Do the upgrade with the official VEX/IFI tools (vexnet upgrade utility V4.1.5 and vexnet key firmware upgrade utility v1.46).

ROBOTC V3.63 and V4.26.
Ignore any warnings about wrong master firmware in the software inspection dialog, keep programming as usual.

Uncheck “Verify vex system” in the download options dialog then program as usual. Upgrade when the next version of EasyC is released.

I think there were probably smarter ways to handle this update, however, that’s a discussion for another time in private.

I guess by security update they mean tech support job security :rolleyes:

Thanks for the info jpearman. Hopefully this will alleviate the forums from “VEXNET ISSUE” post overload.

Everyone that logs onto the website should be forced to read this before they are allowed to make a new post, haha.

Thanks for posting all of this. I don’t know about anyone else, but this situation confuses the heck out of me. I’m not really sure what I absolutely need to do to eek through this weekend’s competition, our first this year.

Our joysticks and cortexes all seem to work fine at our work area but is there a chance things won’t work at a competition because of this upgrade?

We’re using the white keys and we’ve still got whatever upgrades were done to our stuff at Worlds. And I upgraded the RobotC firmware for the version of RobotC that I bought a month or so ago.

So is there a danger things will suddenly stop working at a tournament unless I perform these upgrades/updates? :confused:

No chance, field control does not care about firmware versions.

So VEX would like you to upgrade, and at some point you will need to for other reasons (bugs found, ROBOTC needs a new feature etc.) but if you have a stable system then I would not upgrade straight away. The official line will always be “please upgrade” and I’m sure that by worlds it will be mandatory, but for regional competitions it is extremely unlikely to impact you one way or the other unless there are other undocumented changes to the radio.

I do not intend to upgrade the team yet (we have very old cortexes and it can be tricky) and I only updated one of my three systems out of curiosity. We are on V4.22 in the cortex and do not expect any more VEXnet 2.0 keys in the near future. When ROBOTC V4.27 has been released and few weeks have passed then perhaps I will.

Thank you so much for your incredibly fast reply. You’ve saved whatever little is left of my sanity this week. First competitions are always stressful.

Maybe Vex should eventually develop a flowchart for people to walk through in deciding what to do about these upgrades and when.

VEX, are you reading this? That’s a good idea there. I’m relatively tech savvy and can comprehend all this upgrading mess. But I have several local teams that have contacted me for help with getting their systems upgraded…and while I don’t mind providing assistance, it seems like something that should be documented in a straight forward way so that ANYONE can do it.

Also be warned, upgrading to radio firmware V1.46 is probably a one way process.

Using the vexnet 2.0 V1.43 utility will not allow firmware downgrade, it tries, but the radio will not go into programming mode. Not sure if this is intentional or not but there’s no trying this upgrade out and then reverting back to old firmware as far as I can see.

I can fake it fairly well sometimes, but what’s most confusing to me are the apparent “apples to orangutans” version numbers involved with all these various parts and software packages.

For example. VexNet keys 2.0 use a v1.46 firmware? That, by itself, seems a little confusing to me. It seems to me that a 2.0-something should use a firmware named 2.xx or something. Or use some way of making it more clear what goes with what.

There are many versioning schemes, usually with something like a “1.46” each digit would indicate an order of magnitude difference in functionality.

A jump from 1.43 to 1.44 (or 1.46) may be a minor change, perhaps just a bug fix.
A jump from 1.44 to 1.50 is a more significant.
A jump from 1.43 to 2.00 would be major new functionality, perhaps being incompatible with previous versions.

Sometimes this scheme of “major”, “minor” and “patch” is simplified and reduced to just “major” (the 1.xx ) and “minor” (the x.43), sometimes we add another field which would be a build field, mostly used internally when working on a new version (for example, 1.46build1, 1.46build2 etc).

What has actually happened is that the jump from 1.43 to 1.46 I would consider a significant change, I would have bumped the version to 2.00, but this has always been a contentious issue for software developers and there are many opinions on how to do this (just look at Chrome numbering).

It’s very unusual not to be able to downgrade a “patch” update, I think I know why but not sure I agree with that decision here, I just made a couple of VEXnet keys incompatible with some of my hardware, Oh well, guess they will all be upgraded eventually anyway.

This is all irrelavant for 99.999% of VEX users, if everything is updated then it (should) all work together nicely. There will be a few problems at competitions for a while, I’ve often let other teams borrow keys but there is now the chance that they will update an older key I give them or that it won’t work.

So what qualifies as a very old cortex? Ours date to latter half of 2011 when our team was formed>

We have 4 (or 5?) NC2 units, flat top, from probably 2010. They have intermittent battery connectors (which I need to find a way to deal with) and can be fussy about which PC we connect them to for updates. They are not the oldest ones in circulation but are showing their age.

Thanks for posting this.

Is there some reason that VEX/IFI has not posted the info and what the full path is? Or did I miss the first notice

No idea, this update is in the usual place on the wiki.

The trend has been to not post notice of firmware updates. It would have been useful to announce that VEXnet 2.0 keys were shipping that were incompatible with the firmware included with current versions of EasyC and ROBOTC (wrt master firmware). It would be better to coordinate the release of IFI firmware with new versions of EasyC and ROBOTC, but that never happens and was probably complicated by the fact that older VEXnet 2.0 keys will still be incompatible.